是否有任何理由不听取数据库引擎优化顾问的建议?

时间:2020-03-06 14:47:47  来源:igfitidea点击:

我正在一个团队中,使用SQL Server 2005后端维护.Net Web应用程序。该系统最近在某些地方运行缓慢,因此在完成所有调优工作之后,我们可以想到(添加索引,清理写得不好的存储过程等),我通过Tuning Advisor运行了一个典型的工作负载,吐出大量要创建的其他索引和统计信息列表。我最初的反应是说"确定,我们知道了,SQL Server",但是是否有任何理由不仅仅按照Advisor所说的去做?

解决方案

像所有建议一样,将其与一粒盐一起使用,并用它得出我们自己的结论。

索引有两个问题。

  • 索引占用空间。空间很便宜,因此通常不是针对索引的有力论据。但是,值得考虑。
  • 索引会减慢某些查询(例如插入,更新和删除)的速度。

创建适当的索引是一种平衡。如果没有足够的资源,系统将运行缓慢。如果太多,系统将很慢。对于执行读操作比写操作更多的系统,我们可以添加更多索引。

我认为建议是有帮助的,但在我看来,它仅能为我们提供尝试的机会。我们必须实际进行一些基准测试,看看有什么用,什么没有用。这可能非常耗时,但由于G Mastros指出的原因,可能值得这么做。

数据库优化不是一门简单的科学,而是要为实际情况找到适当​​的平衡。

如果启用了统计信息的自动创建和自动更新(应该),则Sql Server可以很好地管理统计信息,因此请忽略统计信息的建议。进行索引分析,以确保我们可以处理额外的空间需求,并确保它们不会复制某些具有相似列的索引。我们通常可以通过仅添加一两列(注意列的顺序)或者添加包含的列(覆盖索引)来合并索引。

如果索引位于使用大量OLAP的表上,则我们希望将索引限制为5-10. 对于很少获得插入或者更新(每秒少于几张)的表,空间限制应该是唯一需要考虑的问题。

调优向导的建议可能是一个很好的学习工具。取得索引,返回查询计划,并尝试找出为什么确实提出了建议。

请注意DROP INDEX的建议,如果跟踪捕获错过了一些计划的或者罕见的查询,则下次运行时可能会遭受损失。

我建议使用此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

还要注意,数据库调整将在很大程度上取决于使用模式,这可能会在原型设计,开发和生产之间发生很大变化。因此,我最好的建议是在时间充裕的时候调整心脏,并了解更改可能会产生什么影响。一定会在以后为我们服务。