我对数据库优化顾问做了什么错误？

Question

我的背景:我是一个开发/架构师，而不是一个DBA。抱歉的!

因此，我们有一个~400表75 So的数据库。我运行Profiler大约24小时(“调优”模板减去LoginName)，并将~7GB的使用量记录在跟踪文件中。然后，我在这个跟踪文件上运行数据库引擎优化顾问(没有分区，保持聚集索引，PDS推荐:索引)针对我们的生产数据库(小时后)。我给了它4个小时来分析。以下是我得到的总结结果：

在我看来“不对”的突出之处是：

1. 它只调优了~530 k查询中的~9k
2. 它建议我放弃一吨索引(事实上，大多数索引)
3. 它建议我创建0个索引。

你们听起来对吗？我预计它会删除我的大部分索引，但随后会创建大量新的索引。另外，如果分析9k查询需要4个小时，那么让它考虑正常一天的使用是否可行呢？与大多数大型数据库相比，我们的数据库消耗较少(大约50个用户总数)。

我想我不是误解了什么，就是做错了什么。

Answer 1

我不会费心于DTA。这是很多工作的结果，最好是粗略的。每个进入索引调优的人最终都会意识到，它既是一门科学，也是一门艺术，它有很多。您可以使用工具来获得建议，但是盲目地执行这些建议几乎总是会导致问题的发生。

相反，我会给BlitzIndex一个尝试。它将利用Server已经维护的统计信息来确定您可以在哪里改进索引(并在几秒钟内完成)。它还提供了关于如何使用结果的非常容易访问的文档。每个结果都包含一个指向相关文档的链接。这些天我就是这样维护我的索引的。

Answer 2

@JMarx建议的BlitzIndex工具工作得很好！然而，我也发现这个额外的脚本也提供了一些好的建议。不一定要使用它的全部甚至大部分建议，但从顶部摘樱桃是非常有用的！

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

(来源)

我发现的另一个信息是，BlitzIndex和这个脚本在一些事件发生后都是一文不值的：

如果您正在运行Server 2008 R2或更早版本，这是索引使用，因为以下任一项都是最近的，以最近的日期为准：

1. 创建索引时
2. Server上次启动时

如果您正在运行Server 2012，这是索引使用情况，因为有以下任何一个：

1. 创建索引时
2. Server上次启动时
3. 重建索引时(特别是重建命令not )

(来源)