SQL 重叠和多列索引
我正在尝试调整一些存储过程并对索引有疑问。我使用了调优顾问,他们推荐了两个索引,都针对同一个表。问题是一个索引针对一列,另一个索引针对多列,其中它包含第一列中的相同列。我的问题是为什么以及有什么区别?
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]
I am attempting to tune some stored procedures and have a question on indexes. I have used the tuning advisor and they recommended two indexes, both for the same table. The issue is one index is for one column and the other is for multiple columns, of which it includes the same column from the first. My question is why and what is the difference?
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]
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果像上面的情况一样,单列是多列索引中定义的第一列:它并不总是正确的,或者查询工作负载随着时间的推移而改变。如果多列索引有益并且正在使用,则可以删除单列索引。但是,请分析并检查索引使用情况报告。
如果不是,那么它适用于不同的查询。我注意到 DTA 喜欢做的一件事是创建一个索引,该索引本质上是整个表的副本,特别是在查询工作负载由 ORM 发出的情况下。
与本例和所有其他情况一样,进行分析以确定任何索引相对于“正常”查询工作负载的有效性非常重要。
If, as in your case above, the single column is the first column defined in the multi-column index: It doesn't always get it right, OR the query workload has changed over time. If the multi-column index is beneficial and being used, you can delete the single column index. BUT, profile and check the index usage report.
If not, then it is applicable to different queries. One thing I have noticed the DTA likes to do is to create an index which is essentially a copy of the entire table, especially in situations where the query workload is emitted by an ORM.
As with this case and all others, it is important that you profile to determine the effectiveness of any indexes with respect to your 'normal' query workload.
“独立”EfctvEndDate 索引虽然在其他索引中功能可用,但会小得多,因此效率更高(就所需的读取次数及其缓存能力而言,仍然在缓存等中)。
当然,这在很大程度上取决于使用模式等。但是,是的,一般来说,拥有多个明显冗余的索引是一种敏感的方法,这是非常合理的。
索引“重复”的缺点主要是(可能按照影响从大到小的顺序):
因此,必须估计 SELECT 查询的性能改进是否可以从额外的索引中受益,从而抵消上面列出的缺点。数据库性能调整通常是具体情况具体分析的练习......
The "stand alone" EfctvEndDate index, while being functionally available in the other index, will be much smaller, and hence more efficient (with regards to number of reads required, to its ability to be cached, remain in the cache etc. etc.).
This of course depends much on the usage patterns etc. but yes, in general, it is very plausible that having multiple, apparently redundant indexes be a sensitive approach.
The drawbacks of index "duplication" are mainly (and probably in order of bigger to smaller impact):
One must therefore estimate if the improved performance with SELECT queries which can potentially benefit from the extra index(es) offset the drawback listed above. Database performance tuning is typically a case-by-case exercise...