先需要说明的是这篇文章的内容并不是如何调节SQL Server查询性能的（有关这方面的内容能写一本书），而是如何在SQL Server查询性能的调节中利用SET STATISTICS IO和SET STATISTICS TIME这两条被经常忽略的Transact-SQL命令的。

　　从表面上看，查询性能的调节是一件十分简单的事。从本质上讲，我们希望查询的运行速度能够尽可能地快，无论是将查询运行的时间从10分钟缩减为1分钟，还是将运行的时间从2秒钟缩短为1秒种，我们最终的目标都是减少运行的时间。

　　尽管查询性能调节困难的原因有许多，但这篇文章将只涉及其中的一个方面，其中最重要的原因是，每当使用环境发生变化时，就需要对性能进行调节，因此很难搞清楚到底需要如何调节查询的性能。

　　如果象大多数用户那样在一台测试用的服务器上进行性能调查，其效果往往并不是十分地令人满意，因为测试服务器的环境与实际应用的服务器环境并不完全相同。随着对资源要求的不断变化，SQL Server会自动地进行自我调节。

　　如果对这一点有疑问，可以在一台负载很大的服务器上反复地运行同一个查询，在大多数情况下，执行查询所使用的时间并不相同。当然，差距并不大，但其变化足以使性能的调节比它应有的程度要困难一些。

　　这到底是怎么回事儿？是你的想法错了还是在运行查询时，服务器的负载过重？这是引起运行时间增加的原因吗？尽管可以多次反复地运行查询得到一个平均时间，但这样作的工作量很大。我们需要用一种很科学的标准对每次测试时的性能进行比较。

　　测量服务器资源是解决查询性能调节问题的关键。

　　在服务器上执行查询时，会用到许多种服务器资源。其中的一种资源是CPU的占用时间，假设数据库没有发生任何改变，反复地运行同一个查询其CPU的占用时间将是十分接近的。在这里，我指的不是一个查询从运行开始到结束的时间，而是指运行这一查询所需要的CPU资源数量，运行一个查询所需要的时间与服务器的忙碌程度有关。

　　SQL Server需要的另一种资源是IO。无论何时运行查询，SQL Server都必须从数据缓冲区中读取数据（逻辑读），如果所需要的数据没有在缓冲区中，则需要到磁盘上读取（物理读）。

　　从讨论中可以知道，一个查询需要的CPU、IO资源越多，查询运行的速度就越慢，因此，描述查询性能调节任务的另一种方式是，应该以一种使用更少的CPU、IO资源的方式重写查询命令，如果能够以这样一种方式完成查询，查询的性能就会有所提高。

　　如果调节查询性能的目的是让它使用尽可能少的服务器资源，而不是查询运行的时间最短，那么就更容易测试你采取的措施是提高了查询的性能还是降低了查询的性能。尤其是在资源利用不断变化的服务器上更是如此。首先，需要搞清楚在对查询进行调节时，如何测试我们的服务器的资源使用情况。

　　又想起了SET STATISTICS IO和SET STATISTICS TIME

　　SQL Server很早以前就支持SET STATISTICS IO和SET STATISTICS TIME这二条Transact-SQL命令了，但由于其他一些原因，在调节查询的性能时，许多DBA（数据为系统管理员）都忽略了它们，也许是它们不大吸引人吧。但不管是什么原因，我们下面就会发现，它们在调节查询性能方面还是很有用的。

　　有三种方式可以使用这二条命令：使用Transact-SQL命令行方式、使用Query Analyzer、在Query Analyzer中设置当前连接适当的连接属性。在这篇文章中，我们将使用Transact-SQL命令行的方式演示它们的用法。

　　SET STATISTICS IO和SET STATISTICS TIME的作用象开关那样，可以打开或关闭我们的查询使用资源的各种报告信息。缺省状态下，这些设置是关闭的。我们首先来看一个这些命令如何打开的例子，并看看它们会报告一些什么样的信息。