SQL 重叠和多列索引
Posted
技术标签:
【中文标题】SQL 重叠和多列索引【英文标题】:SQL Overlapping and Multi-Column Indexes 【发布时间】:2011-01-25 05:26:32 【问题描述】:我正在尝试调整一些存储过程并且对索引有疑问。我使用了调优顾问,他们推荐了两个索引,都用于同一个表。问题是一个索引用于一列,另一个索引用于多列,其中它包含与第一列相同的列。我的问题是为什么和有什么区别?
CREATE NONCLUSTERED INDEX [_dta_index_Table1_5_2079723603__K23_K17_K13_K12_K2_K10_K22_K14_K19_K20_K9_K11_5_6_7_15_18]
ON [dbo].[Table1] (
[EfctvEndDate] ASC,
[StuLangCodeKey] ASC,
[StuBirCntryCodeKey] ASC,
[StuBirStOrProvncCodeKey] ASC,
[StuKey] ASC,
[GndrCodeKey] ASC,
[EfctvStartDate] ASC,
[StuHspncEnctyIndctr] ASC,
[StuEnctyMsngIndctr] ASC,
[StuRaceMsngIndctr] ASC,
[StuBirDate] ASC,
[StuBirCityName] ASC
) INCLUDE (
[StuFstNameLgl],
[StuLastOrSrnmLgl],
[StuMdlNameLgl],
[StuIneligSnorImgrntIndctr],
[StuExpctdGrdtngClYear]
) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF)
ON [PRIMARY] go
CREATE NONCLUSTERED INDEX [_dta_index_Table1_5_2079723603__K23]
ON [dbo].[Table1] (
[EfctvEndDate] ASC
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF)
ON [PRIMARY]
【问题讨论】:
不是一个确切的副本,但如果您还没有,您可能想阅读此内容:***.com/questions/179085/… 那是因为。不幸的是,答案中的链接已损坏,对相关文章的任何想法可能会更深入。但是,他们说如果重复项是索引中的最后一项,它将被忽略,但在我的情况下,它是两者中的第一项。 【参考方案1】:如果与上述情况一样,单列是多列索引中定义的第一列:它并不总是正确,或者查询工作量随时间而变化。如果多列索引是有益的并且正在使用,您可以删除单列索引。但是,请分析并检查索引使用报告。
如果不是,那么它适用于不同的查询。我注意到 DTA 喜欢做的一件事是创建一个索引,该索引本质上是整个表的副本,尤其是在查询工作负载由 ORM 发出的情况下。
与本案例和所有其他案例一样,重要的是您要进行概要分析以确定任何索引相对于您的“正常”查询工作负载的有效性。
【讨论】:
【参考方案2】:“独立”EfctvEndDate 索引虽然在其他索引中在功能上可用,但会小得多,因此效率更高(就所需的读取次数而言,它能够缓存,保留在缓存中等等)。
这当然在很大程度上取决于使用模式等。但是,是的,一般来说,拥有多个明显冗余的索引是一种敏感的方法是非常合理的。
索引“重复”的缺点主要是(并且可能按照影响从大到小的顺序):
对基础表的 INSERT/UPDATE/DELETE 查询会产生性能开销来维护额外的索引。 缓存使用竞争 [非常] 更长的时间来生成查询计划。 存储开销(通常不是问题;但确实会增加备份时间...)。因此,必须估计 SELECT 查询的改进性能是否可以从额外的索引中受益,从而抵消上面列出的缺点。数据库性能调优通常是逐案练习...
【讨论】:
@Mitch。我淡化了这个断言;-)。我确实坚持认为“冗余”索引非常相关in many cases
。
重复索引也会影响备份,从而影响维护窗口的长度
@Mitch Wheat:所有优点!我认为我们理解争论的双方,并且可能会就特定案例提供类似的建议。然而,在手头的情况下,对备份性能的关注让我微笑:考虑到“超宽”覆盖索引(顺便说一句,用相当有问题的一组键和键序列;我直接回答了 OP,但也许还应该建议他评估这个广泛索引的有效用处)。以上是关于SQL 重叠和多列索引的主要内容,如果未能解决你的问题,请参考以下文章