确定表上的索引未使用

Question

我一直在运行这个脚本来试图找到无关的索引

select o.name as TableName, i.name as IndexName, p.reserved_page_count * 8.0 / 1024 as     SpaceInMB, s.*
from     sys.dm_db_index_usage_stats s
inner join sys.objects o on s.object_id = o.object_id
inner join sys.indexes i on i.index_id = s.index_id and i.object_id = o.object_id
inner join sys.dm_db_partition_stats p on i.index_id = p.index_id and o.object_id =      p.object_id
where o.name = ‘TableName’

我知道当 last_user_seek/scan/lookup 都为空时，自上次重启以来没有用户使用过索引。但我想知道 system_scans/lookups/seeks 是什么？因为在某个表上我发现了 5 个没有用户活动的，但一个在 10 天前有系统活动。有没有人对系统扫描/搜索/查找可能有任何了解？这些表似乎真的过度索引，我想减少脂肪。

Answer 1

索引维护（重建/重组）和 DBCC CHECKDB 活动最有可能，可能是统计更新。是否配置了定期维护？

如果没有用户访问权限，将它们装箱。请注意您决定不再使用它们的时间范围。例如，是否有任何每周或每月报告任务？

在您寻找的同时，还要四处寻找重复的索引。

编辑：关于SSC 链接

快速浏览一下帖子，看起来 SSC 的人也有类似的想法。然而，他们对这些索引可能的“偶尔”使用采取更谨慎的立场，认为有人将它们放在那里是有原因的，这是一个完全合理的论点。相反的论点是，它往往恰恰相反，有人将它们放在那里，因为他们认为这是正确的做法，但由于缺乏理解或缺乏测试，事实并非如此。

除了删除未使用的和重复的索引之外，我什么都不做，已经将几个系统从边缘带回来了。过度索引会导致混乱。

这是您的系统，您需要了解并权衡保留这些索引或删除它们的风险。如果您决定继续投放，请记录您所做的事情、为什么要这样做，编写索引并发布给所有感兴趣的各方。

Answer 2

Glenn Berry 编写了一些很棒的脚本来帮助您找到丢失的索引。我建议使用他的脚本，它可以为您消除一些猜测工作。这些脚本不仅在寻找空或 0 个用户查找/扫描/搜索，而且还在寻找在读取活动和写入活动之间有很大偏差的索引，可能仍然通过删除来获得更好的整体性能。我会检查他的脚本 - 你可以从他的这篇文章开始。

我不会担心系统活动。如果您删除索引，这不会变得更糟，事实上，它可能是仅在该索引上发生的活动，因为它存在。您关心的主要事情是用户读取活动和用户写入活动并平衡它们。

Answer 3

请记住，索引还为查询优化器提供有用的信息，即使它们没有被使用。例如，我在独特性的影响方面做了很多工作。如果您因为没有搜索或扫描而删除唯一索引，您仍然可能对性能产生不利影响。