SQL Server2008优化之SET STATISTICS开关

一、准备工作

缓存对于某个查询的性能影响十分之大,所以优化之前要清空缓存。

清除Buffer Pool时面的所有缓存 DBCC DROPCLEANBUFFERS
清除Buffer Pool里的所有缓存的执行计划,已经预编译的内容,在此处将被清空 DBCC FREEPROCCACHE

二、SET STATISTICS TIME ON/OFF开关

这个开关能输出SQL语句各阶段所消耗的时间
返回值说明: CPU Time,SQL Server所花的纯CPU时间是多少,也就是说语句花了多少CPU资源 elapsed Time,语句运行的时间长短,有些动作会发生I/O操作、产生了I/O等待,或者是遇到阻塞、产生阻塞的等待,总之时间用掉了,但是没有用CPU资源,所以Elapsed Time比CPU Time长是很正常的。但是CPU Time是语句在所有CPU上的时间总和,如果语句使用了多颗CPU,而其他等待几乎没有,那么CPU Time大于Elapsed Time也是正常的。 SQL Server parse and compile time,语句的编译时间 SQL Server Execution Times,语句真正运行的时间

三、SET STATISTICS IO ON/OFF开关

这个开关能够输出语句做的物理读和逻辑读的数
返回值说明: scan count:执行的扫描次数。按照执行计划,表格被Scan了几次。一般来讲大表Scan的次数越多越不好,唯一的例外是如果执行计划选择了并发运行,由多个Thread同时做一个表的读取,每个Thread读其中的一部分,但是这里会显示所有Thread的数目。也就是有几个Thread在并发做,就会有几个Scan。这时数目大一点没问题。 logical reads:从数据缓存读取的页数。页数越多,说明查询要访问的数据量就越大,内存消耗量越大,查询也就越昂贵。可以检查是否应该调整索引,减少扫描的次数,缩小扫描范围。 physical reads:从磁盘读取的页数。 read-ahead reads:为进行查询而预读入缓存的页数。 physical reads + read ahead reads就是SQL Server为了完成这句查询而从磁盘上读取的页数。如果不为0,说明数据没有缓存在内存里,运行速度一定会受到影响。 lob logical reads:从数据缓存读取的Text、Ntext、Image或大值类型(Varchar(max)、Nvarchar(max)、Varbinary(max))页的数目。 lob physical reads:从磁盘读取的Text、Ntext、Image或大值类型页的数目。 lob read-ahead reads:为进行查询而放入缓存的Text、Ntext、Image或大值类型页的数目。

四、SET STATISTICS PROFILE ON/OFF开关

这个开关能返回语句的执行计划,以及语句运行在每一步的实际返回行数
Rows:执行计划的每一步返回的实际行数。 Executes:执行计划的每一步被运行了多少次。 StmtText:执行计划的具体内容。执行计划以一棵树的形式显示。每一行,都是运行的一步,都会有结果集返回,也都会有自己的cost。 EstimateRows:SQL Server根据表格上的统计信息,预估的每一步的返回行数。在分析执行计划时,我们会经常将Rows和EstimateRows这两列做对比,先确认SQL Server预估得是否准确。 EstimateIO:SQL Server根据EstimateRows和统计信息里记录的字段长度,预估的每一步会产生的I/O cost。 EstimateCPU:SQL Server根据EstimateRows和统计信息里记录的字段长度,以及要做的事情的复杂度,预估的每一步会产生的CPU cost。 TotalSubtreeCost:SQL Server根据EstimateIO和EstimateCPU通过某种计算公式,计算出的每一步执行计划子树cost(包括这一步自己的cost和它的所有下层步骤的cost总和)。 Warnings:SQL Server在运行每一步时遇到的警告,例如,某一步没有统计信息支持cost预估等。 Parallel:执行计划的这一步是不是使用了并行的执行计划。

时间: 2024-10-29 19:06:11

SQL Server2008优化之SET STATISTICS开关的相关文章

ORACLE性能优化之SQL语句优化

版权声明:本文为博主原创文章,未经博主允许不得转载. 目录(?)[+] 操作环境:AIX +11g+PLSQL 包含以下内容: 1.  SQL语句执行过程 2.  优化器及执行计划 3.  合理应用Hints 4.  索引及应用实例 5.   其他优化技术及应用 1.SQL语句执行过程 1.1 SQL语句的执行步骤 1)语法分析,分析语句的语法是否符合规范,衡量语句中各表达式的意义. 2)语义分析,检查语句中涉及的所有数据库对象是否存在,且用户有相应的权限. 3)视图转换,将涉及视图的查询语句转

MySQL之SQL语句优化

一 SQL语句优化的一般步骤: 1 通过show status命令了解各种SQL语句的执行频率 mysql> show status;                #show status:显示服务器状态信息 +-----------------------------------------------+-------------+ | Variable_name                                 | Value       | +---------------

转:sql语句优化

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

SQL语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

分析oracle的执行计划(explain plan)并对对sql进行优化实践

基于oracle的应用系统很多性能问题,是由应用系统sql性能低劣引起的,所以,sql的性能优化很重要,分析与优化sql的性能我们一般通过查看该sql的执行计划,本文就如何看懂执行计划,以及如何通过分析执行计划对sql进行优化做相应说明. 一.什么是执行计划(explain plan) 执行计划:一条查询语句在oracle中的执行过程或访问路径的描述. 二.如何查看执行计划 1.set autotrace on 2.explain plan for sql语句; select plan_tabl

Sql效能优化总结(续)- sql语句优化篇

今晚继续进行Sql效能问题的分享,今天主要是一些具体的sql优化方法和思路分享,若看过后你也有其他想法,欢迎一起探讨,好了,进入今天的主题. 针对性地对一些耗资源严重的具体应用进行优化 出现效能问题时,首先要做的是什么?这个问题我问过不少同事,有人说凭经验对出问题的sql进行优化,如我们一般说的要合理使用索引,尽量不要使用前面带*号的Like语句,不要再比较操作符前边进行计算或使用函数等等,这些道路都是对的,但经验有时候不一定能解决问题.问题出现时,首先要做的是确定问题点是什么,只有正确的找到问

SQL Server SQL性能优化之--通过拆分SQL提高执行效率,以及性能高低背后的原因

复杂SQL拆分优化 拆分SQL是性能优化一种非常有效的方法之一, 具体就是将复杂的SQL按照一定的逻辑逐步分解成简单的SQL,借助临时表,最后执行一个等价的逻辑,已达到高效执行的目的 一直想写一遍通过拆分SQL来优化的博文,最近刚好遇到一个实际案例,比较有代表性,现分享出来, 我们来通过一个案例来分析,为什么拆分语句可以提高SQL执行效率,更重要的是弄清楚,拆分前为什么慢,拆分后为什么快了? 幼稚的话,各位看官莫笑 先看一下相关表的数据量,大表也有5900多万,小表有160多万 (声明:我从来没

[转]sql语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜.  连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行

Sql server2005 优化查询速度50个方法小结

Sql server2005 优化查询速度50个方法小结 Sql server2005优化查询速度51法查询速度慢的原因很多,常见如下几种,大家可以参考下. I/O吞吐量小,形成了瓶颈效应.  没有创建计算列导致查询不优化.  内存不足.  网络速度慢.  查询出的数据量过大(可以采用多次查询,其他的方法降低数据量).  锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷).  sp_lock,sp_who,活动的用户查看,原因是读写竞争资源.  返回了不必要的行和列.  查询语句不好,没有