第十章——维护索引(6)——查找无用索引

简介: 原文: 第十章——维护索引(6)——查找无用索引 前言:众所周知,索引对性能的提升有巨大作用。但是这是有代价的,索引需要磁盘空间来存放它的B-Tree,并且用于在每次DML执行后更新信息,所以应该在一定时期内检查有无无用索引。
原文: 第十章——维护索引(6)——查找无用索引

前言:

众所周知,索引对性能的提升有巨大作用。但是这是有代价的,索引需要磁盘空间来存放它的B-Tree,并且用于在每次DML执行后更新信息,所以应该在一定时期内检查有无无用索引。

 

 

准备工作:

记住别在重启服务器之后进行信息收集,因为DMO将会清空,而数据会非常不准确甚至是错误的。所以应该在运行了一段时间后(业务周期)再做收集。

业务周期根据实际情况而定。一些表和查询会每天频繁使用,但是一些类似报表功能可能是一月甚至一年执行一次,所以,除非必要,不然就让所有东西一直运行,知道你的业务周期完毕。这样会得到相对准确的信息。

 

 

步骤:

执行以下语句:

前言:
众所周知,索引对性能的提升有巨大作用。但是这是有代价的,索引需要磁盘空间来存放它的B-Tree,并且用于在每次DML执行后更新信息,所以应该在一定时期内检查有无无用索引。


准备工作:
记住别在重启服务器之后进行信息收集,因为DMO将会清空,而数据会非常不准确甚至是错误的。所以应该在运行了一段时间后(业务周期)再做收集。
业务周期根据实际情况而定。一些表和查询会每天频繁使用,但是一些类似报表功能可能是一月甚至一年执行一次,所以,除非必要,不然就让所有东西一直运行,知道你的业务周期完毕。这样会得到相对准确的信息。


步骤:
执行以下语句:
SELECT  ind.index_id ,
        obj.name AS TableName ,
        ind.name AS IndexName ,
        ind.type_desc ,
        indUsage.user_seeks ,
        indUsage.user_scans ,
        indUsage.user_lookups ,
        indUsage.user_updates ,
        indUsage.last_system_seek ,
        indUsage.last_user_scan ,
        'drop index [' + ind.name + '] ON [' + obj.name + ']' AS DropIndexCommand
FROM    sys.indexes AS ind
        INNER JOIN sys.objects AS obj ON ind.object_id = obj.object_id
        LEFT JOIN sys.dm_db_index_usage_stats indUsage ON ind.object_id = indUsage.object_id
                                                          AND ind.index_id = indUsage.index_id
WHERE   ind.type_desc <> 'HEAP'
        AND obj.type <> 'S'
        AND OBJECTPROPERTY(obj.object_id, 'isusertable') = 1
        AND ( ISNULL(indUsage.user_seeks, 0) = 0
              AND ISNULL(indUsage.user_scans, 0) = 0
              AND ISNULL(indUsage.user_lookups, 0) = 0
            )
ORDER BY obj.name ,
        ind.name
GO

分析:
为了获得索引名、索引类型、表名,有必要关联sys.Indexes和sys.objects表。
通常情况下,当一个索引被使用了,那么在sys.dm_db_index_usage_stats上的user_seek、user_scan、或者user_lookup列上会有一些值。如果索引从来未被使用,那么这些值就为0,也就是没必要保留。

扩充信息:
在决定索引是否有效时,还需要结合你的专业只是。有些索引之所以没有统计数据是因为还没有到使用的周期,或者周期性地重启了服务器,在删除之前,要考虑:
1、	是否为主键或者唯一键,因为及时这部分没有数值,但是它们还是可以很好地保证数据的一致性。
2、	唯一索引帮助优化器创建更有效的执行计划,及时这些索引未被使用,但是也提供了数据分布的相关信息。



分析: 

为了获得索引名、索引类型、表名,有必要关联sys.Indexes和sys.objects表。

通常情况下,当一个索引被使用了,那么在sys.dm_db_index_usage_stats上的user_seek、user_scan、或者user_lookup列上会有一些值。如果索引从来未被使用,那么这些值就为0,也就是没必要保留。

 

扩充信息:

在决定索引是否有效时,还需要结合你的专业只是。有些索引之所以没有统计数据是因为还没有到使用的周期,或者周期性地重启了服务器,在删除之前,要考虑:

1、             是否为主键或者唯一键,因为及时这部分没有数值,但是它们还是可以很好地保证数据的一致性。

2、             唯一索引帮助优化器创建更有效的执行计划,及时这些索引未被使用,但是也提供了数据分布的相关信息。

目录
相关文章
|
存储 索引
【软考学习15】索引文件结构、直接索引和间接索引
【软考学习15】索引文件结构、直接索引和间接索引
389 0
|
7月前
|
存储 关系型数据库 MySQL
mysql索引优化,更好的创建和使用索引
mysql索引优化,更好的创建和使用索引
|
SQL 存储 缓存
索引不是越多越好,理解索引结构原理,才有助于我们建立合适的索引!
MySQL支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此MySQL数据库支持多种索引类型,如BTree索引,哈希索引,全文索引等等。为了避免混乱,本文将只关注于BTree索引,因为这是平常使用MySQL时主要打交道的索引。
662 0
|
数据库 索引
存在逻辑删除的表字段上建立唯一索引的巧办法 (逻辑删除与唯一索引)
设计数据库唯一索引时,经常会碰到唯一删除的键值,导致很难处理,这里就简单介绍一种巧办法,帮你快速解决该问题
2001 0
存在逻辑删除的表字段上建立唯一索引的巧办法 (逻辑删除与唯一索引)
|
关系型数据库 MySQL 索引
二十七、冗余和重复索引
二十七、冗余和重复索引
134 0
|
SQL 关系型数据库 数据库
MySQL优化系列(二)--查找优化(1)(非索引设计)
MySQL优化系列(二)--查找优化(1)(非索引设计) 接下来这篇是查询优化,用户80%的操作基本都在查询,我们有什么理由不去优化他呢??所以这篇博客将会讲解大量的查询优化(索引以及库表结构优化等高级用法后面文章再讲),先讲单表查优化,再讲多表查优化。
1821 0
|
索引
第十章——维护索引(5)——查找丢失索引
原文: 第十章——维护索引(5)——查找丢失索引 前言: 在开发阶段,很难总是可以在合适的列上创建合适的索引。所以一开始创建的索引可能会无效,此时,需要找出这些无效的索引。
896 0