sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME---解释比较详细

一个查询需要的CPU、IO资源越多,查询运行的速度就越慢,因此,描述查询性能调节任务的另一种方式是,应该以一种使用更少的CPU、IO资源的方式重写查询命令,如果能够以这样一种方式完成查询,查询的性能就会有所提高。

如果调节查询性能的目的是让它使用尽可能少的服务器资源,而不是查询运行的时间最短,那么就更容易测试你采取的措施是提高了查询的性能还是降低了查询的性能。尤其是在资源利用不断变化的服务器上更是如此。首先,需要搞清楚在对查询进行调节时,如何测试我们的服务器的资源使用情况。
        在开始我们的例子前,先运行下面的这二条命令(不要在正在使用的服务器上执行),这二条命令将清除SQL Server的数据和过程缓冲区,这样能够使我们在每次执行查询时在同一个起点上,否则,每次执行查询得到的结果就不具有可比性了:
DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE
输入并运行下面的Transact-SQL命令:
SET STATISTICS IO ON  
SET STATISTICS TIME ON
一旦上面的准备工作完成后,运行下面的查询:
SELECT * FROM [order details]

显示结果:
SQL Server parse and compile time: (SQL Server解析和编译时间:)
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的效果

Scan Count:在查询中涉及到的表被访问的次数。在我们的例子中,其中的表只被访问了1次,由于查询中不包括连接命令,这一信息并不是十分有用,但如果查询中包含有一个或多个连接,则这一信息是十分有用的。(一个循环外部的表的Scan Count值为1,但对于一个循环内的表而言,其值为循环的次数。可以想象得到,对于一个循环内的表而言,其ScanCount值越小,它所使用的资源越少,查询的性能也就越高。因此在调节一个带连接的查询的性能时,需要关注Scan Count的值,在进行调节时,注意观察它是增加还是减少了。)

 
Logical Reads: 这是SET STATISTICS IO或SET STATISTICS TIME命令提供的最有用的数据。我们知道,SQL Server在可以对任何数据进行操作前,必须首先把数据读取到其数据缓冲区中。此外,我们也知道SQL Server何时会从数据缓冲区中读取数据,并把数据读取到大小为8K字节的页中。那么LogicalReads的意义是什么呢?Logical Reads是指SQL Server为得到查询中的结果而必须从数据缓冲区读取的页数。在执行查询时,SQL Server不会读取比实际需求多或少的数据,因此,当在相同的数据集上执行同一个查询,得到的LogicalReads的数字总是相同的。(SQL Server执行查询时的Logical Reads值每一次这个数值是不会变化的。因此,在进行查询性能的调节时,这是一个可以用来衡量你的调节措施是否成功的一个很好的标准。如果Logical Reads值下降,就表明查询使用的服务器资源减少,查询的性能有所提高。如果Logical Reads值增加,则表示调节措施降低了查询的性能。在其他条件不变的情况下,一个查询使用的逻辑读越少,其效率就越高,查询的速度就越快。)
Physical Reads:物理读,在执行真正的查询操作前,SQL Server必须从磁盘上向数据缓冲区中读取它所需要的数据。在SQL Server开始执行查询前,它要作的第一件事就是检查它所需要的数据是否在数据缓冲区中,如果在,就从中读取,如果不在,SQLServer必须首先将它需要的数据从磁盘上读到数据缓冲区中。我们可以想象得到,SQL Server在执行物理读时比执行逻辑读需要更多的服务器资源。因此,在理想情况下,我们应当尽量避免物理读操作。下面的这一部分听起来让人容易感到糊涂了。在对查询的性能进行调节时,可以忽略物理读而只专注于逻辑读。你一定会纳闷儿,刚才不是还说物理读比逻辑读需要更多的服务器资源吗?情况确实是这样, SQLServer在执行查询时所需要的物理读次数不可能通过性能调节而减少的。减少物理读的次数是DBA的一项重要工作,但它涉及到整个服务器性能的调节,而不仅仅是查询性能的调节。在进行查询性能调节时,我们不能控制数据缓冲区的大小或服务器的忙碌程度以及完成查询所需要的数据是在数据缓冲区中还是在磁盘上,唯一我们能够控制的数据是得到查询结果所需要执行的逻辑读的次数。因此,在查询性能的调节中,我们可以心安理得地不理会SET STATISTICS IO命令提供的PhysicalRead的值。(减少物理读次数、加快SQL Server运行速度的一种方式是确保服务器的物理内存足够多。)

Read-Ahead Reads: 与Physical Reads一样,这个值在查询性能调节中也没有什么用。Read-Ahead Reads表示SQL Server在执行预读机制时读取的物理页。为了优化其性能,SQL Server在认为它需要数据之前预先读取一部分数据,根据SQLServer对数据需求预测的准确程度,预读的数据页可能有用,也可能没用。在本例中,Read-Ahead Reads的值为9,Physical Read的值为1,而LogicalReads的值为10,它们之间存在着简单的相加关系。
        
          那么我在服务器上执行查询时的过程是怎么样的呢?首先,SQL Server会开始检查完成查询所需要的数据是否在数据缓冲区中,它会很快地发现这些数据不在数据缓冲区中,并启动预读机制将它所需要的10个数据页中的前9个读取到数据缓冲区。当SQL Server检查是否所需要的全部数据都已经在数据缓冲区时,会发现已经有9个数据页在数据缓冲区中,还有一个不在,它就会立即再次读取磁盘,将所需要的页读到数据缓冲区。一旦所有的数据都在数据缓冲区后,SQLServer就可以处理查询了。

总结:在对查询的性能进行调节时用一些科学的标准来测量你的调节措施是否有效是十分重要的。问题是,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( 逻辑读)次数
======================

原文地址:https://www.cnblogs.com/aaronguo/p/11417361.html

时间: 2024-10-10 05:40:44

sql查询性能调试,用SET STATISTICS IO和SET STATISTICS TIME---解释比较详细的相关文章

SET STATISTICS IO和SET STATISTICS TIME 在SQL Server查询性能优化中的作用

原文:SET STATISTICS IO和SET STATISTICS TIME 在SQL Server查询性能优化中的作用 近段时间以来,一直在探究SQL Server查询性能的问题,当然也漫无目的的查找了很多资料,也从网上的大神们的文章中学到了很多,在这里,向各位大神致敬.正是受大神们无私奉献精神的影响,所以小弟也作为回报,分享一下关于SET STATISTICS IO和SET STATISTICS TIME这两条T_SQL命令,在查询优化性能中的作用. 首先我想说明一下这篇文章不是关于如何

利用SET STATISTICS IO和SET STATISTICS TIME 优化SQL Server查询性能

首先需要说明的是这篇文章的内容并不是如何调节SQL Server查询性能的(有关这方面的内容能写一本书),而是如何在SQL Server查询性能的调节中利用SET STATISTICS IO和SET STATISTICS TIME这二条被经常忽略的Transact-SQL命令的. 从表面上看,查询性能的调节是一件十分简单的事.从本质上讲,我们希望查询的运行速度能够尽可能地快,无论是将查询运行的时间从10分钟缩减为1分钟,还是将运行的时间从2秒钟缩短为1秒种,我们最终的目标都是减少运行的时间. 尽

比较SQL查询性能 语句

比较SQL查询性能 语句 --优先使用SET STATISTICS IO和SET STATISTICS TIME查看性能调节是否有效. --SET STATISTICS TIME ON --SET STATISTICS TIME ON 在开始我们的例子前,先运行下面的这二条命令(不要在正在使用的服务器上执行),这二条命令将清除SQL Server的数据和过程缓冲区,这样能够使我们在每次执行查询时在同一个起点上,否则,每次执行查询得到的结果就不具有可比性了:DBCC DROPCLEANBUFFER

sql查询性能分析

SQL查询性能分析 http://blog.csdn.net/dba_huangzj/article/details/7623926 五分钟打造自己的sql性能分析工具 http://www.cnblogs.com/gezifeiyang/p/3403744.html sql查询性能分析,布布扣,bubuko.com

聚焦-移除Bookmark Lookup、RID Lookup、Key Lookup提高SQL查询性能(六)

前言 前面几节都是讲的基础内容,本节我们讲讲索引性能优化,当对大数据进行处理时首先想到的就是索引,一旦遇到这样的问题则手忙脚乱,各种查资料,为何平常不扎实基本功呢,我们由浅入深,简短的内容,深入的理解,而非一上来就把问题给框死,立马给出解决方案,抛出问题,再到解决问题,你GET了没有. Bookmark Lookup.RID Lookup.Key Lookup定义 一说到这三者,如果对索引研究不深的童鞋估计是懵逼的,什么玩意,我们姑且将上面三者翻译为:标签查找.行ID查找.键查找.标签查找和键查

mysql经纬度查询并且计算2KM范围内附近用户的sql查询性能优化实例教程

之前很傻很天真地以为无非就是逐个计算距离,然后比较出来就行了,然后当碰到访问用户很多,而且数据库中经纬度信息很多的时候,计算量的迅速增长,能让服务器完全傻逼掉,还是老前辈的经验比我们丰富,给了我很大的启示. MySQL性能调优 – 使用更为快速的算法进行距离计算 最近遇到了一个问题,通过不断的尝试最终将某句原本占据近1秒的查询优化到了0.01秒,效率提高了100倍. 问题是这样的,有一张存放用户居住地点经纬度信息的MySQL数据表,表结构可以简化 为:id(int),longitude(long

DBA推荐的7法宝提高SQL查询性能

SQL查询数据库时,可以采取一系列的方式来提高查询的速度和性能.比如用case代替update,使用临时表和分批进行更新等.本文介绍了7种提高查询速度的方法,请读者参考. SQL查询数据库时,适当遵循一些原则可以让工作变得更加轻松,本文就列举7个可以灵活运用的原则,它们可以帮助你提高SQL查询速度,当然这些技巧你可以咨询DBA获得更多的信息. 1.用case代替update 要更新一条记录,我们立即会想到update,这个问题非常常见,许多开发人员经常忽视这个原则,因为使用update看起来非常

5种提升SQL查询性能的知识

“SQL性能优化是一种黑魔法就像炼金术一样:各种配方难解晦涩,只有一小部分圈内人才能理解.” 这是一种误解,SQL数据库使用的是大家公知的算法来实现可以预期的执行性能.然而,问题是,人们很容易写出不能发挥最高效算法的SQL查询语句,因而也容易产生无法预期的性能结果. 下面是5道关于SQL性能优化小测试题,这些测试题也许会让你坚信SQL优化就是一种黑魔法.但答案中提供的解释说明会随即让你明白,这些所谓的黑魔法其实是纯粹的科学. 本测试中使用的SQL是基于Oracle数据库. 单从性能的视角看,下面

MariaDb SQL查询性能 注意事项

where,on和order by指定的字段要有索引 复杂计算的结果应在生成后写入 而不是每次读取时计算,除非写的成本大于读 除了分页以外 避免出现count(*)的情况 count数据用一个count字段在写入时累加 判断是否存在使用有短路机制的exists()函数 避免出现使用sum()的情况,应建立单独的表写入时累加相应结果 任何情况下都应该避免使用not in(),应使用in().exists().not exists()和union查询代替 in()当中不能包含SQL查询,如果需要包含