SQL 重叠和多列索引

发布于 2024-08-24 07:44:56 字数 1063 浏览 9 评论 0原文

我正在尝试调整一些存储过程并对索引有疑问。我使用了调优顾问,他们推荐了两个索引,都针对同一个表。问题是一个索引针对一列,另一个索引针对多列,其中它包含第一列中的相同列。我的问题是为什么以及有什么区别?

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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

水晶透心 2024-08-31 07:44:56

如果像上面的情况一样,单列是多列索引中定义的第一列:它并不总是正确的,或者查询工作负载随着时间的推移而改变。如果多列索引有益并且正在使用,则可以删除单列索引。但是,请分析并检查索引使用情况报告。

如果不是,那么它适用于不同的查询。我注意到 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.

贵在坚持 2024-08-31 07:44:56

“独立”EfctvEndDate 索引虽然在其他索引中功能可用,但会小得多,因此效率更高(就所需的读取次数及其缓存能力而言,仍然在缓存等中)。

当然,这在很大程度上取决于使用模式等。但是,是的,一般来说,拥有多个明显冗余的索引是一种敏感的方法,这是非常合理的。

索引“重复”的缺点主要是(可能按照影响从大到小的顺序):

  • 对基础表进行 INSERT/UPDATE/DELETE 查询,会产生维护额外索引的性能开销。
  • 缓存使用的竞争
  • [非常轻微] 更长的时间来生成查询计划。
  • 存储开销(通常不是问题;但是确实会增加备份时间......)。

因此,必须估计 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):

  • INSERT/UPDATE/DELETE queries on the underlying table, incur a performance overhead to maintain the extra index(es).
  • competition for cache usage
  • [very slightly] longer time to produce query plans.
  • storage overhead (typically a non-issue; does increase backup times, however...).

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...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文