对于做管理系统和分析系统的程序员，复杂SQL语句是不可避免的，面对海量数据，有时候经过优化的某一条语句，可以提高执行效率和整体运行性能。如何选择SQL语句，本文提供了两种方法，分别对多条SQL进行量化的分析。
在测试SQL性能的过程中。
一是通过设置STATISTICS查看执行SQL时的系统情况。选项有PROFILE，IO ，TIME。
SET STATISTICS PROFILE ON：显示分析、编译和执行查询所需的时间（以毫秒为单位）。
SET STATISTICS IO ON：报告与语句内引用的每个表的扫描数、逻辑读取数（在高速缓存中访问的页数）和物理读取数（访问磁盘的次数）有关的信息。
SET STATISTICS TIME ON：显示每个查询执行后的结果集，代表查询执行的配置文件。
实例如下：
SET STATISTICS PROFILE ON
SET STATISTICS IO ON
SET STATISTICS TIME ON
GO
–你的SQL脚本开始
SELECT [TestCase] FROM [TestCaseSelect]
–你的SQL脚本结束
GO
SET STATISTICS PROFILE OFF
SET STATISTICS IO OFF
SET STATISTICS TIME OFF
另外，也可以通过手工添加语句，计算执行时间来查看执行语句花费了的时间，以判断该条SQL语句的效率如何：
declare @d datetime
set @d=getdate()
–你的SQL脚本开始
SELECT [TestCase] FROM [TestCaseSelect]
–你的SQL脚本结束
select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())
二是通过SQL 2008的“查询”按钮下的“包括实际的执行计划”和“包括客户端统计信息”。
下面是我和经理写的两个例子的性能对比：
我的：
SQL Server 执行时间:
CPU 时间= 32 毫秒，占用时间= 762 毫秒。
CPU 时间= 16 毫秒，占用时间= 475 毫秒。
CPU 时间= 32 毫秒，占用时间= 671 毫秒。
CPU 时间= 31 毫秒，占用时间= 615 毫秒。经理的：
SQL Server 执行时间:
CPU 时间= 16 毫秒，占用时间= 547 毫秒。
CPU 时间= 47 毫秒，占用时间= 491 毫秒。
CPU 时间= 32 毫秒，占用时间= 436 毫秒。
CPU 时间= 47 毫秒，占用时间= 416 毫秒。
PS：今天在做一道题目的时候，经理给出的一道难题，虽然做出来了，但是性能没有做到最优化。其中用到了三层嵌套。现在特别是要总结的：大表跟小表进行关联查询 时，涉及到嵌套查询，先查询小表，然后再联合大表。我是一开始让大小表进行关联，然后再嵌套。而经理写的是先让小表嵌套，最后在关联。这样，执行效率自然要比我高