一、set statistics time on的作用

显示分析、编译和执行各语句所需的毫秒数。

二、语法

SET STATISTICS TIME { ON | OFF }

注释

1、当 SET STATISTICS TIME 为 ON 时,显示语句的时间统计。一旦执行了上述命令,在整个会话期间,时间统计一直保持启用状态,直到执行 OFF 操作。

2、为 OFF 时,不显示时间统计。

2、SET STATISTICS TIME 的设置是在执行或运行时设置,而不是在分析时设置。

三、set statistics time on实例

 
SQL 代码   复制

 USE AdventureWorks;
GO
SET STATISTICS TIME ON
GO
SELECT *
FROM Production.ProductCostHistory
WHERE StandardCost < 500.00;
GO
SET STATISTICS TIME OFF;
GO

输出结果

 
SQL 代码   复制

  SQL Server 分析和编译时间:
CPU 时间 = 15 毫秒,占用时间 = 104 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。

(4 行受影响)

SQL Server 执行时间:
CPU 时间 = 171 毫秒,占用时间 = 1903 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。

四、set statistics time 的输出的意思

1、CPU时间 

这个值的含义指的是在这一步,SQLSERVER所花的纯CPU时间是多少。也就是说,语句花了多少CPU资源

2、占用时间

此值指这一步一共用了多少时间。也就是说,这是语句运行的时间长短,有些动作会发生I/O操作,产生了I/O等待,

或者是遇到阻塞、产生了阻塞等待。总之时间用掉了,但是没有用CPU资源。所以占用时间比CPU时间长是很正常的 ,但是CPU时间是

语句在所有CPU上的时间总和。如果语句使用了多颗CPU,而其他等待几乎没有,那么CPU时间大于占用时间也是正常的

3、分析和编译时间:

这一步,就是语句的编译时间。由于语句运行之前清空了所有执行计划,SQLSERVER必须要对他编译。

这里的编译时间就不为0了。由于编译主要是CPU的运算,所以一般CPU时间和占用时间是差不多的。如果这里相差比较大,

就有必要看看SQLSERVER在系统资源上有没有瓶颈了。

这里他们是一个15毫秒,一个是104毫秒

4、SQLSERVER执行时间:

语句真正运行的时间。由于语句是第一次运行,SQLSERVER需要把数据从磁盘读到内存里,这里语句的

运行发生了比较长的I/O等待。所以这里的CPU时间和占用时间差别就很大了,一个是171毫秒,而另一个是1903毫秒

总的来讲,这条语句花了104+1903+186=2193毫秒,其中CPU时间为15+171=186毫秒。语句的主要时间应该是都花在了I/O等待上

最新文章

  1. requests的content与text导致lxml的解析问题
  2. C++整数转字符串的一种方法
  3. spring jdbc获取插入记录的主键id
  4. ABAP ALV单个单元格状态编辑
  5. Centos下使用gitosis配置管理git服务端(转载)
  6. MBTiles地图瓦片管理工具
  7. javascript AES加密 C#AES解密实现
  8. PostgreSQL的 initdb 源代码分析之十
  9. 射频识别技术漫谈(1)&mdash;&mdash;概念、分类
  10. linux下date命令实现时间戳与日期的转换
  11. VMware内安装Ubuntu后安装vmtools
  12. [Netty 1] 初识Netty
  13. 编写一个类,其中包含一个排序的方法Sort(),当传入的是一串整数,就按照从小到大的顺序输出,如果传入的是一个字符串,就将字符串反序输出。
  14. 【Java框架型项目从入门到装逼】第四节 - 编写第一个Servlet程序
  15. MongDB配置方法
  16. pandas Dataframe 取某行
  17. 在java服务端判断请求是来自哪个终端
  18. MyBatis关联查询,一对多关联查询
  19. libuv 简单使用
  20. react拖拽(表格拖拽排序、普通拖拽排序以及树形拖拽排序)

热门文章

  1. Mysql主从架构报错-Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work...
  2. OpenStack之基础知识
  3. kerberos master-slave搭建
  4. 20145302张薇 Java第一周学习总结
  5. python爬虫之新浪微博登录
  6. getJson同步
  7. SaltStack使用salt-ssh模式-第十一篇
  8. 异步:asyncio和aiohttp的一些应用(1)
  9. Spring Boot 上传图片文件
  10. js 苹果手机 keyup 事件不生效的问题