是否有任何理由不采纳数据库引擎优化顾问的建议？

我在一个团队维护与SQL Server 2005后端的.Net Web应用程序。最近系统运行速度有点慢，所以在完成所有我们可以想到的调整类型的东西之后（添加索引，清理写入非常糟糕的存储过程等），我通过Tuning Advisor运行了一个典型的工作负载，并且它吐出了一个额外的索引和统计数据创建的巨大列表。我最初的反应是说“当然，你知道了，SQL Server”，但是有没有任何理由不去做顾问说的？是否有任何理由不采纳数据库引擎优化顾问的建议？

来源

2008-09-26 Electrons_Ahoy

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

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

调整向导建议可以是一个很好的学习工具。采取索引，回到查询计划，并试图找出为什么完全是建议。

来源

2008-09-26 17:58:25

像所有的建议一样，用一粒盐，并用它来达到你自己的结论。

来源

2008-09-26 17:43:49

索引有2个问题。

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

创建合适的索引是一种平衡行为。如果你的系统不够用，你的系统会很慢。如果你有太多，你的系统会很慢。对于执行更多读取操作而不是写入操作的系统，您可以放弃添加更多索引。

来源

2008-09-26 17:48:54

我认为这个建议很有帮助，但在我看来它只给你一些东西去尝试。你必须实际做一些基准测试，看看有什么帮助，哪些没有。这可能非常耗时，但可能是G Mastros指出的原因。

数据库优化不是一个直截了当的科学，而是一个为你确切的情况找到适当平衡的问题。

来源

2008-09-26 17:58:25

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

来源

2008-09-26 20:14:57 Meff

我推荐这个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

来源

2008-09-27 01:03:01

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

来源

2008-09-27 01:24:43