对于查询调优，你需要的不止STATISTICS IO

在我查询调优期间，STATISTICS IO会话选项是我的朋友，因为对于指定的查询，它准确告诉你有多少页已读取。每次，SQL Server从缓存池骑牛一个8K的页，它通过STATISTICS IO的输出获得记录。

通常我会建议启用STATISTICS IO来更好的理解在给定的查询里，涉及的表上有多少页被读取。而且查询调优的目标是尽可能减少这些读取页数——通过索引策略。对于查询，你数据读的越少，查询就会越快。但今天的问题如下：对于查询调优，STATISTICS IO有你需要的一切么，还是又你应该知道更多的维度？

我们来谈下客户端统计信息

另一个非常重要的选项——至少从我的角度来看——是SSMS里的客户端统计信息选项：

当对你的会话启用这个选项，SSMS会告诉你你的查询客户端处理的更多信息。下图是SSMS里一个典型的输出结果：

这里SSMS向你展示你的查询最后一次执行的性能指标。最重要的指标是网络统计和时间统计。网络统计信息向你展示下列信息：

• 服务器往返的次数
• 从客户端发送的 TDS 数据包
• 从服务器接收的 TDS 数据包
• 从客户端发送的字节数
• 从服务器接收的字节数

通常我会留意从服务器接收的字节数，因为用收到的信息，你很容易看到从服务器返回的信息量。当然你的结果集越大，你返回的数据越多，你的查询时间也会更长。我在客户这遇到过有返回几G数据的查询，他们还在抱怨为什么查询这么慢，额~~~~~这个……

另外时间统计信息向你展示了下列信息：

•   客户端处理时间
•   总执行时间
•   服务器应答等待时间

这里最重要的维度是客户端处理时间，因为它告诉你SSMS本身需要多长时间来处理你的查询。这里的大部分时间是SSMS用在计算和可视化结果集。同理，结果集越大，SSMS花更多的时间来可视化它，因此查询时间会更长。

小结

STATISTICS IO是查询调优的很好开始，另外我也使用来自客户统计信息的输出来更好的理解有多少数据在网络上传输，SSMS本身需要花多少时间来处理数据。

因此下次你的查询慢的时候，你可以使用客户统计信息来检查在SSMS里的时间花费。或许查询本身很快，但是SSMS需要更多的时间。

感谢关注！

原文链接

https://www.sqlpassion.at/archive/2017/03/27/do-you-need-more-than-statistics-io-for-query-tuning/