我正在使用 SQL Server 2008。我注意到，当我运行存储过程并包含执行计划时，如果我“丢失”索引，SQL Server 将包含一个警报，并会推荐一个让我按顺序添加提高存储过程的性能。
至少对我来说，我认为让我的自动化测试运行一些性能更密集的存储过程然后在 XML 中包含一个执行计划是有意义的。然后，解析 XML 计划以查找 SQL Server 发出的任何警告或警报。如果遇到任何问题，则认为这是测试失败。如果自上次运行以来某些查询成本显着增加，我可以更进一步并抛出失败，但现在我只是保持简单。
这听起来像是有人已经做过的事情，但我在谷歌上没有看到任何东西。这是一种合理的自动化性能测试/基准测试方法吗？如果是，是否有任何现有的工具或框架可以让这变得更容易？
谢谢，
泰德兹
【问题讨论】：
标签： sql sql-server performance sql-server-2008 testing
我建议不要这样做。优化器识别的缺失索引非常短视。也就是说，他们没有考虑整个系统，并建议可能有利于该查询但可能会降低 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 何时将其性能改变到足以进入列表，并在它下降时查看您的调整工作的影响。
【讨论】：