确定表上的索引未使用

我一直在运行此脚本以尝试查找无关的索引

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全部为null时，自上次重新启动以来，没有用户使用该索引。但是我想知道system_scans / lookups / seeks是什么？因为在某张桌子上我发现5位用户没有活动，但是10天前一个用户有系统活动。是否有人对什么系统扫描/搜索/查找有任何见识？这些表似乎索引过大，我想减少脂肪。

索引维护（重建/重组）和DBCC CHECKDB活动最有可能，可能是统计信息更新。是否配置了任何计划的维护？

如果没有用户访问权限，则将其分类。请记住您决定不再使用它们的时间范围。例如，是否有每周或每月的报告任务？

在查找的同时，还要挖掘重复的索引。

编辑：关于SSC链接

通过对线程的快速扫描，看起来SSC员工有类似的想法。但是，对于这些索引可能的“偶尔”使用，他们持更加谨慎的态度，采取的立场是有人出于某种理由将它们放在那里，这是一个完全合理的论点。相反的论点是，通常情况恰恰相反，有人把他们放在那里是因为他们认为这样做是对的，但由于缺乏了解或缺乏测试，事实并非如此。

除了删除未使用的和重复的索引之外，我什么也做不了，从而使几个系统濒临崩溃。过度索引会导致混乱。

这是您的系统，您需要了解并权衡保留这些索引或将其删除的风险。如果您决定继续进行删除，请记录您的操作，执行原因，编写索引脚本并将其发布给所有感兴趣的各方。

Glenn Berry编写了一些出色的脚本来帮助您找到丢失的索引。我建议使用他的脚本，这些脚本可以为您消除一些猜测工作。这些脚本不仅要查找null或0个用户的查找/扫描/查找，而且还要查找在读活动和写活动之间有较大偏差的索引，可能仍会因删除而导致更好的整体性能。我会检查一下他的脚本-您可以从他的这篇文章开始。

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

请记住，即使不使用索引，索引也可以为Query Optimizer提供有用的信息。例如，我已经对“唯一性”的影响做了很多工作。如果您删除唯一索引，因为它没有搜索或扫描，则仍然会对性能造成不利影响。

除了其他人都说过的以外，对引用的FK列的索引可能永远不会显示搜索或扫描，而是在幕后使用。