1.前言
对于优化SQL语句或存储过程，以前主要是用如下语句来判断具体执行时间，但是SQL环境是复杂多变的，下面语句并不能精准判断性能是否提高；如果需要精确知道CPU、IO等信息，就无能为力了。
|
1
2
3
|
PRINT convert(varchar(30),getdate(),121)
select * from Sales.SalesOrderDetail where SalesOrderID > 64185
PRINT convert(varchar(30),getdate(),121)
|
这时候如果使用SET STATISTICS TIME ON和SET STATISTICS IO ON 指令就能清楚的知道了，在测试之前需执行下面2条命令
DBCC DROPCLEANBUFFERS 清除缓冲区
DBCC FREEPROCCACHE 删除计划高速缓存中的元素
2.测试
2.1 首先执行下面脚本
|
1
2
3
4
5
6
7
|
--开启统计信息SET STATISTICS TIME ON
SET STATISTICS IO ON
GOselect * from Sales.SalesOrderDetail where SalesOrderID > 64185
GO |
结果如下
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
--1.SQL Server 分析和编译时间: CPU 时间 = 0 毫秒，占用时间 = 53 毫秒。
--2.SQL Server 分析和编译时间: CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
(35292 行受影响)--3.表 ‘SalesOrderDetail‘。扫描计数 1，逻辑读取 337 次，物理读取 4 次，预读 333 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。--4. SQL Server 执行时间:
CPU 时间 = 47 毫秒，占用时间 = 893 毫秒。
|
说明：
标记1：表示将语句的结果放到SQL缓冲区所需要的CPU时间和总时间
标记2：标识从缓冲区中取出解析结果所需要的时间
标记4：标识这次查询使用了多少CPU时间和总的时间，其中CPU时间是对查询所需CPU资源的一种比较稳定的测量方式；总时间则跟SQL服务器有关，因此比较不稳定；所以性能判断的时候可以以CPU时间来做标准。
标记3：资源时间；其中逻辑读是指SQL从缓冲区读取的数据；物理读是指从数据从磁盘读取到缓冲区中；
2.2 再次运行查询语句结果如下，由于第一次执行的时候，数据已经从磁盘读取到缓冲区，因此标记1的时间也就是0了，标记3物理读也为0了。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
--1.SQL Server 分析和编译时间: CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
--2.SQL Server 分析和编译时间: CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
(35292 行受影响)--3.表 ‘SalesOrderDetail‘。扫描计数 1，逻辑读取 337 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。--4. SQL Server 执行时间:
CPU 时间 = 32 毫秒，占用时间 = 848 毫秒。
|
2.3 在优化SQL语句的时候可以从CPU时间，逻辑读取数来判断性能是否提升，而且这2个指标是比较真实的反映了SQL执行情况的。这里只是简单介绍了一下这2个命令的一些基本信息，则需更加深入了解SQL底层知识。
https://www.cnblogs.com/xqhppt/p/4041799.html
Sql Server性能优化辅助指标SET STATISTICS TIME ON和SET STATISTICS IO ON