查询性能调优

Question

当您编写完查询/存储的proc/函数时，最快获得一些性能参数的信息最丰富的方法是什么？是否运行查询并查看实际执行计划？如果是的话，你要找的是什么？显然，表/索引扫描是点击率，但还有什么呢？

Answer 1

为了进行快速评估，请将执行计划从SSMS中取出并输入到计划探索者中。

• 检查最昂贵的操作是否有意外发生。排序、工作表、不适当的联接运算符(例如，嵌套循环，您期望合并或散列)。
• 看看计划的每一个阶段的排数，它们是否大致在你期望看到的范围之内？
• 看一下估计的和实际的行。如果你的实际情况接近估计值，你就更有可能有一个好的计划。如果有很大的变化，找出原因(例如缺少和/或过时的统计数据)。
• 评估潜在的参数嗅探问题。查找基数可能变化的区域，并根据一系列输入参数进行测试。

很多免费提供的参考资料，格兰特费奇利的服务器执行计划是一个良好的开端。我还发现关于执行计划的张乔博客文章和电子书非常有用。

Answer 2

大多数情况下，我所做的就是运行这个查询，并了解它是如何针对现实世界的数据执行的。如果有问题，我看一下执行计划。

至于执行计划，布拉德McGehee有关于这个问题的一篇有趣的文章。

他在信中说：

如果在执行计划中看到以下任何一项，则应考虑它们的警告标志，并调查它们的潜在性能问题。从性能的角度来看，它们中的每一个都不太理想。*索引或表扫描:可能表示需要更好的或更多的索引。* Bookmark查找:考虑更改当前聚集索引，考虑使用覆盖索引，限制SELECT语句中的列数。* Filter:删除WHERE子句中的任何函数，在Transact-SQL代码中不包括wiews碳化硅，可能需要额外的索引。*排序:数据真的需要排序吗？索引可以用来避免排序吗？能够更有效地在客户端进行排序吗？避免这种情况并不总是可能的，但是您越能避免它们，查询性能就会越快。

Answer 3

SET STATISTICS IO ON

一般来说，“逻辑读取的数量”应该尽可能低。完成查询的页面越少，计划越好，因为它(通常)会更快，对CPU、RAM和磁盘IO的影响越小。

这将指导您更改索引或重新分解SQL实际上是有帮助的。查看“毫秒过剩时间”，即使使用相同的SQL和查询计划，也会发生变化--对于任何给定的查询计划，逻辑读取都将保持一致。

此外，“物理读取”应该非常低(对于后续的执行，应该是零和保持零)。如果没有这样做，那么查看您的Server内存使用情况(页面生存期等)。