删除不必要的索引-对SQL Server 2005中的查询计划的影响

下面是我们在2MM记录表（SQLServer2005）上的索引混乱的一部分。很明显，我们有机会把它们说出来。这个表总共有16个索引，包括

[MemberID]、[RegistryID]、[end_date]

上的聚集PK，但我只列出了似乎需要合并的索引

例如，我很想放弃

[ix_IndexName7]

，因为这是多余的。但是根据sys.dm\u db\u index\u usage\u stats

这是我的问题。比方说我放弃了

[ix_IndexName7]

或

[ix_IndexName30]

（我认为

[idxmemberregistery1]

中涵盖了这一点）。当查询计划试图查找

[ix_IndexName7]

但无法找到时，优化器会神奇地合并第一列为

[MemberID]

的其他索引之一吗？或者我必须找到使用该表的任何SP/视图/函数并重新编译它们（这会很糟糕，因为可能有大量垃圾）。还是别的什么

我希望这个问题是清楚的。如果您有任何意见，我将不胜感激

CREATE NONCLUSTERED INDEX [idx_RegistryID] ON [dbo].[Member_Registry] ([RegistryId], [end_date], [MemberId])
CREATE UNIQUE NONCLUSTERED INDEX [idx_MemberID] ON [dbo].[Member_Registry] ([MemberId], [RegistryId], [end_date]) INCLUDE ([Due_Date])
CREATE NONCLUSTERED INDEX [ix_IndexName7] ON [dbo].[Member_Registry] ([end_date]) INCLUDE ([MemberId])
CREATE NONCLUSTERED INDEX [ix_IndexName11] ON [dbo].[Member_Registry] ([end_date]) INCLUDE ([MemberId], [RegistryId])
CREATE NONCLUSTERED INDEX [ix_IndexName16] ON [dbo].[Member_Registry] ([end_date]) INCLUDE ([ContinuousEnrol], [MemberId], [RegistryId])
CREATE NONCLUSTERED INDEX [ix_IndexName30] ON [dbo].[Member_Registry] ([end_date]) INCLUDE ([MemberId], [P4P_Patient], [RegistryId])
CREATE NONCLUSTERED INDEX [ix_IndexName29] ON [dbo].[Member_Registry] ([end_date], [ContinuousEnrol]) INCLUDE ([MemberId], [RegistryId])
CREATE NONCLUSTERED INDEX [idxMemberRegistry1] ON [dbo].[Member_Registry] ([end_date], [MemberId], [RegistryId]) INCLUDE ([COL_D2yr], [ContinuousEnrol], [P4P_AAB], [P4P_ACE], [P4P_CERVICAL], [P4P_Chlamydia], [P4P_COL], [P4P_DGX], [P4P_DIU], [P4P_MAMMO], [P4P_Patient], [start_date])
CREATE NONCLUSTERED INDEX [idx_AllPatients] ON [dbo].[Member_Registry] ([MemberId], [RegistryId], [end_date]) INCLUDE ([EXCLUSION_STATUS], [P4P_Patient])
CREATE NONCLUSTERED INDEX [idx_Exclusion_Status] ON [dbo].[Member_Registry] ([MemberId], [RegistryId], [EXCLUSION_STATUS])

---

当查询计划的源发生某些类型的更改时，查询计划将无效。这将包括删除它正在使用的任何索引。未使用无效的查询计划

---

在缓存中找不到有效的匹配查询计划，挂起的查询只会生成一个新的…

如果删除一些索引并再次运行查询，它将重新编译一个新的执行计划，可能会使用一些剩余的索引，也可能不会。这是一个测试的问题，看谁的行动将帮助最大，或相反，将破坏所有的性能

在讨论索引时，这些脚本肯定能方便地做出决定：

• 也来自@Brent Ozar
• 来自Jason Strate
• 奥拉哈伦格伦酒店

---

它们一起提供了大量有关索引、重复项、未使用项、统计信息、等待状态、I/O使用等的当前状态的信息。根据这些信息，您可以进行更精确的分析，并选择最佳选项。

我的建议：运行格伦超级酷列表中的查询4和查询5。。。。。。。。。。请记住，平衡性能的一部分是插入/更新/删除的成本。删除一些大大加快很少使用的查询速度的索引，例如年终报告，可能会在提高写操作性能方面获得值得的回报。从索引7回退到11可能对读取的影响最小，但会简化写入。这完全取决于您的数据和工作量。非常感谢大家！我会听取大家的意见。不幸的是，这个数据库是一个灾难性的区域，有数百个过时的对象，这是一个经常被引用的表，但我会尽可能彻底地测试它。就你的观点而言，@HABO，我了解了sys.dm\u db\u index\u usage\u stats.user\u updates列的含义，并肯定会将其纳入我的决策中。另外，考虑到我们在这台服务器上还有大约20GB的空间（叹气），大小与使用之间的权衡可能是相关的。很高兴我们能帮助Anna。别忘了把对你有用的答案作为正确答案进行核对，这样别人路过时就知道该去哪里看了。