多重索引个性：边界重复键答案

【问题标题】：Multiple Index Personalities: Borderline duplicate keys多重索引个性：边界重复键
【发布时间】：2021-07-13 20:03:52
【问题描述】：

我正在从 Brent Ozar 运行 sp_BlitzIndex，并获得了一些这样的项目。

Multiple Index Personalities: Borderline duplicate keys

我不是 100% 知道该怎么做，但下面是一个示例。

CREATE INDEX [IX_Test] ON [Test] ( [SportId] ) WITH (FILLFACTOR=100, ONLINE=?, SORT_IN_TEMPDB=?, DATA_COMPRESSION=?);

CREATE UNIQUE INDEX [IX_Test_2] ON [Test] ( [SportId], [AnotherId] ) WITH (FILLFACTOR=100, ONLINE=?, SORT_IN_TEMPDB=?, DATA_COMPRESSION=?);

如您所见，它们看起来很相似。我的问题是删除第一个索引 SportID 但保留双索引 (SportId, TextId) 是否有害。

我最好的方法是什么？

【问题讨论】：

保留第二个索引是有道理的，第一个索引可能会被某些查询选择，因为它稍微窄一些，但添加可能是单个 int 列应该无关紧要。检查sys.dm_db_index_usage_stats 以了解每个当前的使用情况。
我建议删除第一个索引。第二个是多余的。
你能回答并说明为什么它是多余的吗？

标签： sql sql-server database indexing non-clustered-index

【解决方案1】：

第一个索引 IX_Test 是多余的，因为它的第一个最具选择性的列由索引 IX_Test_2 复制。

这两个索引都可以满足 SportId 的键或范围对特定行的搜索，第二个索引还包括一个附加列，因此覆盖了需要两者或按 AnotherId 排序的查询。

在没有第一个索引的情况下，优化器可以同样好地利用第二个索引，并且添加单个 int 列虽然使索引稍宽，但可以忽略不计，并且可以通过减少的开销来抵消必须保持两者。

【讨论】：

一旦较宽的一个在“memory”/plan/“cache”中，SQL 将永远不会加载第一个。它只是在混杂中造成混乱。
@SqlSurfer 我认为这不对。 AFAIK 编译器忽略缓存/缓冲池中的索引，它只考虑理论成本。因此，如果更窄的索引就足够了，那么即使已经缓存的更宽的索引就足够了，它也会被加载到内存中。