查询性能调优

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

为了进行快速评估，请从SSMS中获取执行计划，然后进入Plan Explorer。

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

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

通常，我要做的只是运行查询，并找出如何针对实际数据执行查询。如果有问题，那么我来看看执行计划。

至于执行计划，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? 

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

SET STATISTICS IO ON

通常，“逻辑读取数”应尽可能低。触摸完成查询所需的页面数越少，计划越好（因为通常会更快），因此对CPU，RAM和磁盘IO的影响较小。

这将在更改索引或SQL重构真正有帮助时为您提供指导。即使使用相同的SQL和查询计划，“毫秒执行时间”也会有所不同-逻辑读取对于任何给定的查询计划将保持一致。

同样，“物理读取”应非常低（并且为零，并在后续执行中保持为零）。如果这样做不这样做，请查看您的SQL Server内存使用情况（页面寿命等）。