Question

我们有一个表格，其中包含准备发送的所有电子邮件以及已发送的电子邮件。该表包含超过100万行。

以下是查找仍需要发送的消息的查询。在5次错误之后，不再尝试消息，需要手动修复。 <{1}}仍然是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

（旁注：这个索引的建议大小为5,850,573 KB（？），这个数字是6 GB，对我来说根本没有任何意义。）

我的问题是这个建议索引有意义吗？例如，为什么包含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]列，而查询中不需要它（据我所知）？就我对索引的了解而言，它们应该是快速查找以找到相关行。如果我必须自己设计索引，我会想出类似的东西：

ID

优化器真的很聪明，还是我的索引效率更高，可能更好？

Answer 1

选择索引有两个不同的方面，查找行所需的字段（=实际索引字段）以及之后需要的字段（=包含的字段）。如果您总是排在前15行，则可以完全忽略包含的字段，因为15个keylookup会很快 - 并且将整个电子邮件添加到索引会使其变得非常大。

对于索引字段，了解大部分数据符合您的条件非常重要。

假设几乎所有行都有ErrorCount＆lt; 5，你不应该把它放在索引中 - 但如果它是一个罕见的情况，那么它有好处。

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

在索引中使用CreatedDate取决于从具有ErrorCount和SentDate条件的表中找到的平均行数。如果它是很多（数千）那么它可能有助于它在那里，所以最新的可以快速找到。

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

数据库引擎优化顾问建议改进

1 个答案: