来自 SQL Server Management Studio 的令人困惑的性能建议答案

【问题标题】：Confusing performance advice from SQL Server Management Studio来自 SQL Server Management Studio 的令人困惑的性能建议
【发布时间】：2019-09-12 18:24:57
【问题描述】：

我正在努力提高我们的 SQL 性能。 SQL Server Management Studio 给出了一个令我惊讶的建议。为了示例，我将简化表结构和 SSMS 给出的建议。

Person的表结构：

身份证
名字
姓氏
date_of_birth
电子邮件

我有一个特定的查询，我展示了它的执行计划。然后我看到了 SSMS 给出的建议，这让我有点惊讶。建议添加两个具有以下签名的索引，分别将性能提高 41% 和 53%：

CREATE NONCLUSTERED INDEX [person_1]
  ON [Person]([first_name],[last_name])
  INCLUDE ([id],[date_of_birth],[email])

CREATE NONCLUSTERED INDEX [person_2]
  ON [Person]([first_name],[last_name])
  INCLUDE ([id],[email])

这两个索引在同一列上。只有 INCLUDE 列不同。我从阅读索引中的理解是，第一个索引也包括第二个索引的数据。那么为什么 SSMS 推荐第二个索引，而第一个索引已经包含了需要的数据呢？

【问题讨论】：

我无法解释为什么 SSMS 推荐这两个索引。正如您所注意到的，第一个索引是第二个索引的超集，因此不需要第二个索引。我的猜测是您有一个非常复杂的查询，查询的不同部分可能使用一个或另一个索引。或者，使它们不同的索引之间可能存在细微的区别，例如按降序排列的列。
我同意你的看法。如果您已经有了第一个，则第二个无关紧要。也许......如果您的查询不使用列date_of_birth，它可能会稍微快一点；但差异可能可以忽略不计。
感谢两位的意见。我给出的例子确实是一个非常大而复杂的查询的简化。我有点信任 SSMS，但审稿人说他不理解这个建议。好在不要再盲目相信它了。

标签： sql sql-server tsql database-indexes sql-server-performance

【解决方案1】：

永远不要使用 SSMS 建议。该建议基于特定查询。

而是探索系统视图，例如 sys.dm_db_missing_index_details。查看更多关于sys.dm_db_missing_index_details

或在 SQL Server Diagnostic Information Queries for April 2019 上查看 Glenn Berry 的 DMV 查询

... 或者更好的是 Brent Ozar sp_blitzindex BrentOzarULTD/SQL-Server-First-Responder-Kit

… 或者接受这个查询

SELECT DB_NAME(database_id) AS database_name, 
       OBJECT_NAME(object_id, database_id) AS table_name, 
       mid.equality_columns, 
       mid.inequality_columns, 
       mid.included_columns, 
       (migs.user_seeks + migs.user_scans) * migs.avg_user_impact AS Impact, 
       migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) AS Score, 
       migs.user_seeks, 
       migs.user_scans
FROM sys.dm_db_missing_index_details mid
     INNER JOIN sys.dm_db_missing_index_groups mig ON mid.index_handle = mig.index_handle
     INNER JOIN sys.dm_db_missing_index_group_stats migs ON mig.index_group_handle = migs.group_handle
ORDER BY migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) DESC;

【讨论】：