比较SQL查询性能 语句

比较SQL查询性能 语句

--优先使用SET STATISTICS IO和SET STATISTICS
TIME查看性能调节是否有效。

--SET STATISTICS TIME ON

--SET STATISTICS TIME
ON

在开始我们的例子前,先运行下面的这二条命令(不要在正在使用的服务器上执行),
这二条命令将清除SQL
Server的数据和过程缓冲区,这样能够使我们在每次执行查询时在同一个起点上,否则,每次执行查询得到的结果就不具有可比性了:
DBCC
DROPCLEANBUFFERS
DBCC FREEPROCCACHE

SET STATISTICS TIME

SET STATISTICS TIME ON

select sum(totalamount)sumat,tenderno from
IF_MIDDLE_TEST --your sql

SET STATISTICS TIME OFF

结果对比:
-- CPU 时间 = 1560 毫秒,占用时间 = 7229 毫秒。
--todaydateindex:CPU 时间 =
1435 毫秒,占用时间 = 10340 毫秒。
--shonoindex: CPU 时间 = 1606 毫秒,占用时间 = 7918
毫秒。
--***both index***: CPU 时间 = 1295 毫秒,占用时间 = 2624 毫秒。

由于CPU占用时间是相对稳定的,因此可以使用这一数据作为衡量你的调节措施是提高了查询性能还是降低了查询的性能的一种方法。

SET STATISTICS IO

SET STATISTICS
IO的输出信息显示在输出的结束处,下面是它显示的一个例子:

   Table ‘Order Details‘. Scan
count 1, logical reads 10, physical reads 1, read-ahead reads
9.

Scan
Count:在查询中涉及到的表被访问的次数。在我们的例子中,其中的表只被访问了1次,由于查询中不包括连接命令,这一信息并不是十分有用,但如果查询中包含有一个或多个连接,则这一信息是十分有用的。

Logical Reads: 这是SET STATISTICS IO或SET STATISTICS
TIME命令提供的最有用的数据。我们知道,SQL Server在可以对任何数据进行操作前,必须首先把数据读取到其数据缓冲区中。此外,我们也知道SQL
Server何时会从数据缓冲区中读取数据,并把数据读取到大小为8K字节的页中。
  那么Logical
Reads的意义是什么呢?Logical Reads是指SQL Server为得到查询中的结果而必须从数据缓冲区读取的页数。在执行查询时,SQL
Server不会读取比实际需求多或少的数据,因此,当在相同的数据集上执行同一个查询,得到的Logical
Reads的数字总是相同的。
  为什么说在调节查询性能中知道SQL Server执行查询时的Logical
Reads值是很重要的呢?因为在每次执行同一查询时,这个数值是不会变化的。因此,在进行查询性能的调节时,这是一个可以用来衡量你的调节措施是否成功的一个很好的标准。
  在对查询的性能进行调节时,如果Logical
Reads值下降,就表明查询使用的服务器资源减少,查询的性能有所提高。如果Logical
Reads值增加,则表示调节措施降低了查询的性能。在其他条件不变的情况下,一个查询使用的逻辑读越少,其效率就越高,查询的速度就越快。

Physical
Reads:

  物理读指的是,在执行真正的查询操作前,SQL
Server必须从磁盘上向数据缓冲区中读取它所需要的数据。在SQL
Server开始执行查询前,它要作的第一件事就是检查它所需要的数据是否在数据缓冲区中,如果在,就从中读取,如果不在,SQL
Server必须首先将它需要的数据从磁盘上读到数据缓冲区中。
 我们可以想象得到,SQL
Server在执行物理读时比执行逻辑读需要更多的服务器资源。因此,在理想情况下,我们应当尽量避免物理读操作。

情况确实是这样,SQL
Server在执行查询时所需要的物理读次数不可能通过性能调节而减少的。减少物理读的次数是DBA的一项重要工作,但它涉及到整个服务器性能的调节,而不仅仅是查询性能的调节。在进行查询性能调节时,我们不能控制数据缓冲区的大小或服务器的忙碌程度以及完成查询所需要的数据是在数据缓冲区中还是在磁盘上,唯一我们能够控制的数据是得到查询结果所需要执行的逻辑读的次数。

小结: 

在对查询的性能进行调节时用一些科学的标准来测量你的调节措施是否有效是十分重要的。问题是,SQL
Servers的负载是动态变化的,使用查询总的运行时间来衡量你正在调节性能的查询的性能是提高了还是没有,并不是一个合理的方法

  更好的方法是比较多个数据,例如逻辑读的次数或者查询所使用的CPU时间。因此在对查询的性能进行调节时,需要首先使用SET
STATISTICS IO和SET STATISTICS
TIME
命令向你提供一些必要的数据,以便确定你对查询性能进行调节的措施是否真正地得到了目的。

其他相关:
set statistics io on
set statistics profile on
set statistics
io off
set statistics profile off

时间: 2024-10-24 22:00:59

比较SQL查询性能 语句的相关文章

sql查询性能分析

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

【知了堂学习笔记】SQL查询基础语句(单表查询、多表查询)

SQL查询基础 1.单表查询 从数据库中查找数据 专业的称谓又称为投影 基本查询语句结构 select 列 from 表 * 所有列不是所有其他东西 查询所有数据 例:SELECT * FROM t_studen 需要执行比较细的操作  加上条件筛选:查询id为2号的学生信息 SELECT * FROM t_student WHERE id=2; 筛选的执行步骤 例:SELECT * FROM t_student WHERE id=2; SELECT *          (3) 再查询  筛选

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数据库. 单从性能的视角看,下面

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

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

SQL 查询性能优化----解决书签查找

先来看看什么是书签查找: 当优化器所选择的非聚簇索引只包含查询请求的一部分字段时,就需要一个查找(lookup)来检索其他字段来满足请求.对一个有聚簇索引的表来说是一个键查找(key lookup),对一个堆表来说是一个RID查找(RID lookup).这种查找即是——书签查找. 书签查找根据索引的行定位器从表中读取数据.因此,除了索引页面的逻辑读取外,还需要数据页面的逻辑读取. 从索引的行定位器到从表中读取数据这之间会产生一些额外的开销,本文就来解决这个开销. 先看下我的测试表结构: 其中可

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

一个查询需要的CPU.IO资源越多,查询运行的速度就越慢,因此,描述查询性能调节任务的另一种方式是,应该以一种使用更少的CPU.IO资源的方式重写查询命令,如果能够以这样一种方式完成查询,查询的性能就会有所提高. 如果调节查询性能的目的是让它使用尽可能少的服务器资源,而不是查询运行的时间最短,那么就更容易测试你采取的措施是提高了查询的性能还是降低了查询的性能.尤其是在资源利用不断变化的服务器上更是如此.首先,需要搞清楚在对查询进行调节时,如何测试我们的服务器的资源使用情况.        在开始

MariaDb SQL查询性能 注意事项

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