查询性能调优

Question

当您完成查询/存储过程/函数的编写后，快速获取一些性能参数的最有用的方法是什么？您是否运行查询并查看实际执行计划？如果是这样，您要寻找的东西是什么？显然表/索引扫描是位命中，但还有什么？

Answer 1

要进行快速评估，请从 SSMS 中获取执行计划并进入Plan Explorer。

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

那里有许多免费可用的参考资料，Grant Fitchley 的SQL Server 执行计划是一个好的开始。我还发现Joe Chang 的博客文章和关于执行计划成本的电子书非常有用。

Answer 2

大多数情况下，我所做的只是运行查询并找出它如何针对实际数据执行。如果有问题，那么我会查看执行计划。

至于执行计划，Brad McGehee 有一篇关于这个主题的有趣文章。

他在其中说：

如果您在执行计划中看到以下任何内容，您应该考虑它们的警告信号并调查它们是否存在潜在的性能问题。从性能的角度来看，它们中的每一个都不理想。

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, don’t include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

并非总是可以避免这些，但是您可以避免的越多，查询性能就会越快。