set showplan on 查询计划信息
set statistics io on
set statistics time on
set noexec on 编译不执行
set fmtonly on 数据库在接收到客户端对数据的请求之后，直接从系统表中获取数据列信息，生成空的结果集直接返回客户端，而不再对磁盘中存储的数据进行检索处理。
先设置set fmtonly on，再设置set showplan on，编译不执行可以看到查询计划信息。但若开启set statistics io on，set statistics time on看不出相关信息，值都为0。
set forceplan on 强迫查询按照FROM子句中指定的顺序使用表。
set table count 10 优化器优化时连接涉及表的张数，增加Table count意味着编译时间也会增加，因为优化器会用更的时间评价各种连接混合体。
sp_cachestrategy 设置状态Bit来开启或者关闭预取和获取-丢弃缓存策略。
sp_cachestrategy db_name, table_name, index_name
sp_cachestrategy db_name, table_name, "table only", mru, "on"
sp_cachestrategy db_name, table_name, "table only", prefetch, "on"
set paralle1_degree 10 设置能够用于查询的并发执行的工作进程最大数目。譔值<=最大并发度配置参数值。
dbcc traceon(302，301)
运行
set statistics io on
set statistics time on
后，执行关联查询获得查询统计信息如下：
Parse and Compile Time 0.
SQL Server cpu time: 0 ms.
Table: table1 scan count 1, logical reads: (regular=1 apf=0 total=1), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: table2 scan count 238, logical reads: (regular=27 apf=0 total=27), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 0
Execution Time 0.
SQL Server cpu time: 0 ms. SQL Server elapsed time: 0 ms.
(1 row affected)
参数说明：
logical reads：
regular 在高速缓存中找到查询所需的某页的次数；在此只对非由异步预取 (APF) 引入的页进行计数。
apf 在高速缓存中找到由 APF 请求所引入的某请求的次数
total regular 和 apf 逻辑读取数的总和
physical reads：
regular 通过常规异步 I/O 将缓冲区引入高速缓存的次数
apf 由 APF 将缓冲区引入高速缓存的次数
total regular 和 apf 物理读取数的总和
apf IOs used 由 APF 引入的缓冲区数，在查询过程中会用到这些缓冲区中的一页或多页
扫描计数(Scan Count)：在查询中涉及到的表被访问的次数。在我们的例子中，其中的表只被访问了1次，由于查询中不包括连接命令，这一信息并不是十分有用，但如果查询中包含有一个或多个连接，则这一信息是十分有用的。（一个循环外部的表的Scan Count值为1，但对于一个循环内的表而言，其值为循环的次数。可以想象得到，对于一个循环内的表而言，其Scan Count值越小，它所使用的资源越少，查询的性能也就越高。因此在调节一个带连接的查询的性能时，需要关注Scan Count的值，在进行调节时，注意观察它是增加还是减少了。）
逻辑读取(Logical Reads)：这是SET STATISTICS IO或SET STATISTICS TIME命令提供的最有用的 数据。我们知道，数据库在可以对任何数据进行操作前，必须首先把数据读取到其数据缓冲区中。此外，我们也知道数据库何时会从数据缓冲区中读取数据，并把数据读取到大小为8K字节的页中。那么Logical Reads的意义是什么呢？Logical Reads是指数据库为得到查询中的结果而必须从数据缓冲区读取的页数。在执行查询时，数据库不会读取比实际需求多或少的数据，因此，当在相同的数据集上执行同一个查询，得到的Logical Reads的数字总是相同的。（数据库执行查询时的Logical Reads值每一次这个数值是不会变化的。因此，在进行查询性能的调节时，这是一个可以用来衡量你的调节措施是否成功的一个很好的标准。如果 Logical Reads值下降，就表明查询使用的服务器资源减少，查询的性能有所提高。如果Logical Reads值增加，则表示调节措施降低了查询的性能。在其他条件不变的情况下，一个查询使用的逻辑读越少，其效率就越高，查询的速度就越快。）
物理读取(Physical Reads)：物理读，在执行真正的查询操作前，数据库必须从磁盘上向数据缓冲区中读取它所需要的数据。在数据库开始执行查询前，它要作的第一件事就是检查它所需要的数据是否在数据缓冲区中，如果在，就从中读取，如果不在，数据库必须首先将它需要的数据从磁盘上读到数据缓冲区中。我们可以想象得到，数据库在执行物理读时比执行逻辑读需要更多的服务器资源。因此，在理想情况下，我们应当尽量避免物理读操作。下面的这一部分听起来让人容易感到糊涂 了。在对查询的性能进行调节时，可以忽略物理读而只专注于逻辑读。你一定会纳闷儿，刚才不是还说物理读比逻辑读需要更多的服务器资源吗？情况确实是这样， 数据库在执行查询时所需要的物理读次数不可能通过性能调节而减少的。减少物理读的次数是DBA的一项重要工作，但它涉及到整个服务器性能的调节，而 不仅仅是查询性能的调节。在进行查询性能调节时，我们不能控制数据缓冲区的大小或服务器的忙碌程度以及完成查询所需要的数据是在数据缓冲区中还是在磁盘 上，唯一我们能够控制的数据是得到查询结果所需要执行的逻辑读的次数。
因此，在查询性能的调节中，我们可以心安理得地不理会SET STATISTICS IO命令提供的Physical Read的值。（减少物理读次数、加快数据库运行速度的一种方式是确保服务器的物理内存足够多。）
一般在数据库的查询优化过程中，Logic Read是至关重要的，它的计数一般与查询出来的结果集数量成正比，与数据读取的速度也成正比。因此，我们便可以从中看出整个查询（复杂语句，包括存储过程等）中的瓶颈所在，从而进行优化。