DB Engine Tuning Advisor 建议改进

DB Engine Tuning Advisor suggestion improvement

我们有一个 table,它包含所有准备发送和已经发送的电子邮件。 table 包含超过 100 万行。

下面是查找仍需要发送的消息的查询。出现 5 次错误后,将不再尝试发送消息,需要手动修复。 SentDate 保持 null 直到消息被发送。

SELECT TOP (15) 
    ID,
    FromEmailAddress,
    FromEmailDisplayName,
    ReplyToEmailAddress,
    ToEmailAddresses,
    CCEmailAddresses,
    BCCEmailAddresses,
    [Subject],
    Body,
    AttachmentUrl
FROM sysEmailMessage
WHERE ErrorCount < 5 
AND SentDate IS NULL
ORDER BY CreatedDate 

查询速度很慢,我认为是由于缺少索引。我已将查询提供给数据库引擎优化顾问。它建议以下索引(和一些我通常忽略的统计数据):

SET ANSI_PADDING ON

CREATE NONCLUSTERED INDEX [_dta_index_sysEmailMessage_7_1703677117__K14_K1_K12_5_6_7_8_9_10_11_15_17_18] ON [dbo].[sysEmailMessage]
(
    [SentDate] ASC,
    [ID] ASC,
    [ErrorCount] ASC
)
INCLUDE (   [FromEmailAddress],
    [ToEmailAddresses],
    [CCEmailAddresses],
    [BCCEmailAddresses],
    [Subject],
    [Body],
    [AttachmentUrl],
    [CreatedDate],
    [FromEmailDisplayName],
    [ReplyToEmailAddress]) WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]

(旁注:该索引的建议大小为 5,850,573 KB(?)接近 6 GB,对我来说根本没有任何意义。)

我的问题是这个建议的索引是否有意义?例如,为什么包含 ID 列,而查询中不需要它(据我所知)? 就我对索引的了解而言,它们意味着可以快速查找以找到相关行。如果我必须自己设计索引,我会想出类似的东西:

SET ANSI_PADDING ON

CREATE NONCLUSTERED INDEX [index_alternative_a] ON [dbo].[sysEmailMessage]
(
    [SentDate] ASC,
    [ErrorCount] ASC
)
WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]

优化器真的很聪明,还是我的索引更高效、可能更好?

选择索引有两个不同的方面,查找行所需的字段(=实际索引字段),以及之后需要的字段(=包含的字段)。如果您总是处理前 15 行,您可以完全忽略包含的字段,因为 15 个关键字查找会很快——并且将整个电子邮件添加到索引会使它变得巨大。

对于索引字段,了解有多大百分比的数据符合您的条件非常重要。

假设几乎所有行的 ErrorCount < 5,您不应该将其包含在索引中——但如果这种情况很少见,那么最好包含它。

假设 SentDate 很少为 NULL,那么您应该将其作为索引的第一列。

索引中是否包含 CreatedDate 取决于使用 ErrorCount 和 SentDate 条件从 table 中找到的平均行数。如果它很多(数千),那么将它放在那里可能会有所帮助,以便可以快速找到最新的。

但与往常一样,有几项因素会影响性能,因此您应该测试不同的选项对您的环境有何影响。