我正在使用 SQL Server 2008。我注意到，当我运行一个存储过程并包含一个执行计划时，如果我“丢失”一个索引，SQL Server 将包含一个警报，并会推荐一个给我添加以增加存储过程的性能。
至少对我来说，我认为我的自动化测试运行一些性能更密集的存储过程然后在 XML 中包含一个执行计划是有意义的。然后，解析 XML 计划以查找 SQL Server 发出的任何警告或警报。如果遇到任何情况，则认为这是测试失败。如果自上次运行它以来某些查询成本显着增加，我可以更进一步并抛出失败，但现在我只是保持简单。
这听起来像是有人已经做过的事情，但我没有从谷歌上看到任何东西。这是自动化性能测试/基准测试的合理方法吗？如果是，是否有任何现有的工具或框架可以使这更容易？
谢谢，
泰德兹
我建议不要这样做。优化器识别的缺失索引非常短视。也就是说，他们没有考虑整个系统，并建议可能有利于该查询但可能会降低 DML 性能的索引。虽然您的心在正确的位置，但索引分析更像是艺术而不是科学（尽管后者可以而且应该为前者提供信息）。
对此的建议是有效的。我已经看到缺少的索引 dmv 推荐了六个索引，它们都是对同一事物的调整。我已经看到它建议将聚集键添加为包含列（真的很奇怪，因为聚集键总是在索引上）。我已经看到它推荐了已经存在的索引。永远不要只应用这些索引。我认为您最好从缺少的索引 dmv 开始，找到那些有意义的索引以进行更彻底的调查（高影响等）。然后，在 xml 中查询导致推荐这些索引的过程。我很难做到这一点。我们每天刷新我们的计划缓存，并且使用 9K procs 和来自遗留应用程序的大量内联 sql，解析 xml 所需的时间是令人望而却步的。
或者，从 proc stats dmv (sys.dm_exec_procedure_stats) 开始并查询 stats dmv(sys.dm_exec_query_stats)。找出在平均持续时间、cpu 和 i/o 方面最差的 proc。检查该子集是否有丢失的索引（并仔细查看查询本身。）一旦完成，您就可以开始查看性能正常但执行如此频繁以至于即使是很小的改进也可以执行的过程/查询有明显的系统影响。
我每天收集性能统计数据，并为一堆不同的类别（总 cpu、平均 cpu 等）加载前 20 个最差 procs 的汇总表。可以很容易地查看 proc 何时更改其性能足以进入列表，并在它下降时查看调整工作的影响。