sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME
来源:互联网 发布:java核心技术 编辑:程序博客网 时间:2024/06/10 02:37
如果调节查询性能的目的是让它使用尽可能少的服务器资源,而不是查询运行的时间最短,那么就更容易测试你采取的措施是提高了查询的性能还是降低了查询的性能。尤其是在资源利用不断变化的服务器上更是如此。首先,需要搞清楚在对查询进行调节时,如何测试我们的服务器的资源使用情况。
在开始我们的例子前,先运行下面的这二条命令(不要在正在使用的服务器上执行),这二条命令将清除SQL Server的数据和过程缓冲区,这样能够使我们在每次执行查询时在同一个起点上,否则,每次执行查询得到的结果就不具有可比性了:DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE
输入并运行下面的Transact-SQL命令:
SET STATISTICS IO ON
SET STATISTICS TIME ON
一旦上面的准备工作完成后,运行下面的查询:
SELECT * FROM [order details]
CPU time = 10 ms, elapsed time = 61 ms. ……(1)
SQL Server parse and compile time: (SQL Server解析和编译时间:)
CPU time = 0 ms, elapsed time = 0 ms. ……(2)
(所影响的行数为 2155 行) ……(3)
Table 'Order Details'. Scan count 1, logical reads 10, physical reads 1, read-ahead reads 9.
(表:Order Details,扫描次数 1,逻辑读 10,物理读 1,提前读取 9) ……(4)
SQL Server Execution Times:
(SQL Server执行时间:)
CPU time = 30 ms, elapsed time = 387 ms. ……(5)
标志(1)表示SQL Server解析“ELECT * FROM [order details]”命令并将解析的结果放到SQL Server的过程缓冲区中供SQL Server使用所需要的CPU运行时间和总的时间。
标志(2)表示SQL Server从过程缓冲区中取出解析结果供执行的时间,大多数情况下这二个值都会是0,因为这个过程执行得相当地快。
标志(5)表示执行这次查询使用了多少CPU运行时间和运行查询使用了多少时间。CPU运行时间是对运行查询所需要的CPU资源的一种相对稳定的测量方法,与CPU的忙闲程度没有关系。但是,每次运行查询时这一数字也会有所不同,只是变化的范围没有总时间变化大。总时间是对查询执行所需要的时间(不计算阻塞或读数据的时间),由于服务器上的负载是在不断变化的,因此这一数据的变化范围有时会相当地大。(由于CPU占用时间是相对稳定的,因此可以使用这一数据作为衡量你的调节措施是提高了查询性能还是降低了查询的性能的一种方法。)
标志(4)是SET STATISTICS IO的效果
因此,在查询性能的调节中,我们可以心安理得地不理会SET STATISTICS IO命令提供的Physical Read的值。(减少物理读次数、加快SQL Server运行速度的一种方式是确保服务器的物理内存足够多。)Read-Ahead Reads: 与Physical Reads一样,这个值在查询性能调节中也没有什么用。Read-Ahead Reads表示SQL Server在执行预读机制时读取的物理页。为了优化其性能,SQL Server在认为它需要数据之前预先读取一部分数据,根据SQL Server对数据需求预测的准确程度,预读的数据页可能有用,也可能没用。
在本例中,Read-Ahead Reads的值为9,Physical Read的值为1,而Logical Reads的值为10,它们之间存在着简单的相加关系。那么我在服务器上执行查询时的过程是怎么样的呢?首先,SQL Server会开始检查完成查询所需要的数据是否在数据缓冲区中,它会很快地发现这些数据不在数据缓冲区中,并启动预读机制将它所需要的10个数据页中的 前9个读取到数据缓冲区。当SQL Server检查是否所需要的全部数据都已经在数据缓冲区时,会发现已经有9个数据页在数据缓冲区中,还有一个不在,它就会立即再次读取磁盘,将所需要的 页读到数据缓冲区。一旦所有的数据都在数据缓冲区后,SQL Server就可以处理查询了。
总结:在对查询的性能进行调节时用一些科学的标准来测量你的调节措施是否有效是十分重要的。问题是,SQL Servers的负载是动态变化的,使用查询总的运行时间来衡量你正在调节性能的查询的性能是提高了还是没有,并不是一个合理的方法。
更好的方法是比较多个数据,例如逻辑读的次数或者查询所使用的CPU时间。因此在对查询的性能进行调节时,需要首先使用SET STATISTICS IO和SET STATISTICS TIME命令向你提供一些必要的数据,以便确定你对查询性能进行调节的措施是否真正地得到了目的。
======================
1.测试前用二条命令清除SQL Server的数据和过程缓冲区,以保证测试条件相同:
DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE
2.SET STATISTICS TIME:看cpu时间
3.SET STATISTICS IO:关注scan count(计数)------查询读取的表数量 logical read( 逻辑读)次数
======================
PS:经测试确认SqlServer 2005中对表的连接条件会自动进行优化,但为了养成良好的习惯和在其他数据库上开发的性能考虑,需继续保持大表连接字段放在左边的习惯。
- sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME
- SQL SERV ER 查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME
- sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME
- sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME---解释比较详细
- sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME
- 【转】sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME
- sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME
- sql性能调试,set statistics io 和 set statistics time
- sql性能调试-讲解set statistics io 和 set statistics time (转)
- 利用SET STATISTICS IO和SET STATISTICS TIME 优化SQL Server查询性能
- 利用SET STATISTICS IO和SET STATISTICS TIME 优化SQL Server查询性能
- Transact-SQL命令----SET STATISTICS IO和SET STATISTICS TIME
- Sql Server性能优化辅助指标SET STATISTICS TIME ON和SET STATISTICS IO ON
- SQL Server: 利用 SET STATISTICS IO 和 SET STATISTICS TIME 对T-SQL语句进行性能分析
- set statistics io / set statistics time结果解释(MSSQL)
- 理解Set Statistics IO
- SET STATISTICS IO检查所产生的读和写/SET STATISTICS TIME检查运行时间(ZT)
- SQL Server读懂语句运行的统计信息 SET STATISTICS TIME IO PROFILE ON
- C++11 nullptr
- mysql大数据高并发处理(转载)
- java实习--json格式串记录
- Delphi上位机
- 15-读乐嘉《本色》
- sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME
- Nginx在Linux和windows下的安装使用
- 数据库重要概念解释
- Android Universal Image Loader 源码分析
- C#类型简述
- IOS 类和对象
- 缓存 异步(优秀)
- 异常处理
- 【树分治】poj1741