是否有任何理由不接受数据库引擎优化顾问的建议？答案

【问题标题】：Is there ever any reason not to take the advice of the Database Engine Tuning Advisor?是否有任何理由不接受数据库引擎优化顾问的建议？
【发布时间】：2010-09-13 13:00:40
【问题描述】：

我在一个团队维护一个带有 SQL Server 2005 后端的 .Net Web 应用程序。系统最近在某些地方运行得有点慢，所以在做了所有我们能想到的调优工作（添加索引、清理写得很糟糕的存储过程等）之后，我通过调优顾问运行了一个典型的工作负载 - 并且它吐出大量要创建的附加索引和统计信息。我最初的反应是说“当然，你明白了，SQL Server”，但是有什么理由不按照顾问所说的去做吗？

【问题讨论】：

标签： asp.net sql-server performance

【解决方案1】：

如果您启用了统计信息的自动创建和自动更新（您应该），Sql Server 可以很好地管理统计信息，因此请忽略统计信息建议。获取索引并分析它们以确保您可以处理额外的空间需求，并确保它们不会重复具有相似列的其他索引。您通常可以通过仅添加一两列（注意列的顺序）或添加包含列（覆盖索引）来合并索引。

如果索引位于使用大量 OLAP 的表上，您希望将索引限制为 5-10。对于很少进行插入或更新（每秒少于几次）的表，空间限制应该是唯一的问题。

调整向导建议是一个很好的学习工具。获取索引，返回查询计划并尝试找出提出建议的确切原因。

【讨论】：

【解决方案2】：

索引有两个问题。

索引占用空间。空间很便宜，所以这通常不是反对索引的有力论据。但是，值得考虑。
索引会减慢某些查询（如插入、更新和删除）。

创建适当的索引是一种平衡行为。如果你没有足够的，你的系统会很慢。如果你有太多，你的系统会很慢。对于执行读取多于写入的系统，您可以添加更多索引。

【讨论】：

【解决方案3】：

我推荐这个 SQL 脚本；它使用 SQL 2005 的内置性能计数器来建议索引：

SELECT
  migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure,
  'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle)
  + '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']'
  + ' ON ' + mid.statement
  + ' (' + ISNULL (mid.equality_columns,'')
    + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END
    + ISNULL (mid.inequality_columns, '')
  + ')'
  + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement,
  migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) > 10
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

【讨论】：

【解决方案4】：

它在 computed 列上建议了索引。

然后prevents users from inserting rows into the table。

所以要小心这样的事情。

【讨论】：

哦，那不错！是的，这会导致一些问题。

【解决方案5】：

我认为这些建议很有帮助，但在我看来，它只会给你一些尝试的东西。您实际上必须进行一些基准测试，看看哪些有帮助，哪些没有。这可能非常耗时，但由于 G Mastros 指出的原因，这可能是值得的。

数据库优化不是一门直截了当的科学，而是针对您的具体情况取得适当平衡的问题。

【讨论】：

【解决方案6】：

小心它的 DROP INDEX 建议 - 如果您的跟踪捕获错过了一些计划或罕见的查询，他们可能会在下次运行时受到影响。

【讨论】：

【解决方案7】：

另请注意，数据库调整很大程度上取决于您的使用模式，这可能会在原型设计、开发和生产之间发生很大变化。所以我最好的建议是现在就调整你的心，当你有时间的时候，了解你的改变可能会产生什么影响。以后一定会为您服务的。

【讨论】：

【解决方案8】：

就像所有的建议一样，对它持保留态度，并用它来得出你自己的结论。

【讨论】：