性能调优:理解Set Statistics IO输出

原文:性能调优:理解Set Statistics IO输出

性能调优是DBA的重要工作之一。很多人会带着各种性能上的问题来问我们。我们需要通过SQL Server知识来处理这些问题。经常被问到的一个问题是:早上这个存储过程运行时间还是可以的,但到了晚上就很慢很慢。对此,我们可以笑着回答:这个存储过程运行多次后,已经累趴了,所以很慢。

存储过程或语句运行时间取决于服务器的工作量。如果在晚上,服务器负担很重的话,你的存储过程可能需要更多的时间来运行,因为它在等待CPU周期(CPU cycle)和IO完成(IO completion)。为了获得一致的响应时间,我们需要减少执行完成的资源需求,那就是所谓的性能调优。

IO和CPU是完成执行的主要资源使用对象。更少的资源使用,更稳定的性能表现。这篇文章我们来理解下性能调优中DBCC STATISTCS IO所扮演的角色。

默认情况下SET STATISTCS IO是停用的,我们可以通过下列语句在当前会话级别打开。

1 SET STATISTICS IO  ON

这个语句可以帮助我们获得在语句执行时,所发生IO数(页读/写)。我们来看一个例子的输出。

 1 USE StatisticsDB
 2 GO
 3 SELECT * INTO SalesOrderDetail FROM AdventureWorks2008R2.Sales.SalesOrderDetail
 4 GO
 5 SET STATISTICS IO ON
 6 DBCC dropcleanbuffers
 7 DBCC freeproccache
 8 GO
 9 SELECT * FROM SalesOrderDetail
10 GO
11 SELECT * FROM SalesOrderDetail 

Set Statistics IO的输出信息可以在消息TAB页里找到。同样的语句我们执行了2次,第一次是在清空缓存后执行,第2次没有。

我们来看下输出信息:

扫描计数(Scan count):

根据微软在线帮助,扫描计数是在任何方向都达到叶级别后启动的查询/扫描数,目的在于检索用于构造输出的最终数据集的所有值。

  • 如果使用的索引是主键的唯一索引或聚集索引并且您仅查找一个值,则扫描计数为 0。 例如 WHERE Primary_Key_Column = <value>。
  • 当您使用对非主键列定义的非唯一的聚集索引搜索一个值时,扫描计数为 1。 这是为了针对您正在搜索的键值检查重复值。 例如 WHERE Clustered_Index_Key_Column = <value>。
  • 当 N 为通过使用索引键定位键值后,在叶级别的左侧或右侧启动的不同查找/扫描数时,则扫描计数为 N。

这个数字告诉我们优化器所选择的计划,对这个对象的重复读取次数。很多人误以为这个是对整张表的读取次数,这是完全错误的。

我们通过一个例子来理解扫描计数。

 1 CREATE TABLE ScanCount (Id INT IDENTITY(1,1),Value CHAR(1))
 2 INSERT INTO ScanCount (Value ) VALUES (‘A‘) ,(‘B‘),(‘C‘),(‘D‘), (‘E‘) , (‘F‘)
 3 CREATE UNIQUE CLUSTERED INDEX ix_ScanCount ON ScanCount(Id)
 4
 5 SET STATISTICS IO ON
 6 --Unique clustered Index used to search single value
 7 SELECT * FROM ScanCount  WHERE Id =1
 8 --Unique clustered Index used to search multiple value
 9 SELECT * FROM ScanCount  WHERE Id IN(1,2,3,4,5,6)
10 --Unique clustered Index used to search multiple value
11 SELECT * FROM ScanCount  WHERE Id BETWEEN 1 AND 6

我们来看下上面3个查询语句的输出。

在第1个SELECT语句的输出里,扫描计数为0。这和MSDN里在线帮助“如果使用的索引是主键的唯一索引或聚集索引并且您仅查找一个值,则扫描计数为 0。”描述一致。因为它是唯一索引(聚集/非聚集索引),不需要在叶子层,进行进一步的向左或向右扫描,因为这里只有一个值来匹配。那也是在唯一索引上查找单一值,扫描计数为0的原因。扫描计数是1的话,会在非唯一索引(聚集或非聚集索引)上发生。

对于第2个SELECT语句,扫描计数是6.这是因为我们在找多个不同值。MSDN在线帮助对此有详细说明: “如果使用的索引是主键的唯一索引或非聚集索引,你在查找N个值,则扫描计数为N。”。

我们来看看执行计划里的SEEK谓语,将更清晰:

即使只有一个where条件,还是会分裂成多个谓语。对于每个SEEK谓语,它会生成1个扫描数。

对于最后一个SELECT语句,扫描计数为1,因为MSDN在线帮助说了: “当 N 为通过使用索引键定位键值后,在叶级别的左侧或右侧启动的不同查找/扫描数时,则扫描计数为 N。” 在叶子节点聚集索引结构用来找到1值后,叶子层的向左扫描开始,直到找到值6。我们看下执行计划里的SEEK 谓语,将更清晰:

逻辑读取(logical Read):

从数据缓存读取的页数。数字越小,性能越好。在性能调优中这个数字非常重要。因为它不会随着执行又执行而改变,除非数据或查询语句有变动。在进行性能调优时,这个可以作为性能提升的重要参考。

物理读取(physical reads):

从磁盘读取的页数。这个会随着执行又执行而改变。大多数情况下,连续第2次的执行时,它的物理读取值为0(可以参考上面连续查询的物理读取数变化)。

如果连续执行后,物理读取次数下降了,我们可以假定是服务器上内存使用配置的错误,或者服务器工作量饱和,有内存压力。你需要在服务器级别思考问题的原因。在查询调优时,这个数字不太重要,因为它一直在变,对于下降这个值,你不能对它做出太多控制。

预读 (read-ahead reads):

为进行查询而放入缓存的页数。这个值告诉我们物理页读取数,即SQL Server执行的,作为预读机制的一部分。在查询执行请求那些可能用到页之前,SQL Server把物理数据页读入缓存,用于完成接下来查询的页需要。

可以看到,物理读取是2次,预读是946次。这就是说,查询执行请求了2个页,并预读了946个页到数据缓存,SQL Server估计下次查询可能要用到这些页。和物理读取一样,这个值对在查询调优里并不重要。

lob 逻辑读取(lob logical reads):

从数据缓存读取的 text、ntext、image 或大值类型 (varchar(max)、nvarchar(max)、varbinary(max)) 页的数目。这个和逻辑读一样重要,我们要非常重视。

lob 物理读取(lob physical reads):

从磁盘读取的 text、ntext、image 或大值类型页的数目。

lob 预读(lob read-ahead reads):

为进行查询而放入缓存的 text、ntext、image 或大值类型页的数目。

总结下,逻辑读取和LOB逻辑读取是2个重要数值,在性能调优时,我们要重点围观。如果把这2个值调低,不在本文的讨论范围。通常创建合适的索引或重写查询可以帮助我们彻底降低这2个值。

时间: 2024-11-05 06:12:50

性能调优:理解Set Statistics IO输出的相关文章

性能调优:理解Set Statistics Time输出

在性能调优:理解Set Statistics IO输出我们讨论了Set Statistics IO,还有如何帮助我们进行性能调优.这篇文章会讨论下Set Statistics Time,它会告诉我们执行一个查询需要的时间. 我们用一个例子来开始. 1 USE AdventureWorks2008r2 2 GO 3 DBCC dropcleanbuffers 4 DBCC freeproccache 5 6 GO 7 SET STATISTICS TIME ON 8 GO 9 SELECT * 1

理解统计信息(3/6):谁创建和管理统计信息?在性能调优中,统计信息的作用。

在理解统计信息(2/6):直方图 中,我们讨论了直方图,密度,还有SQL Server如何用统计信息做基数预估(cardinality estimation).这篇文章会讨论统计信息如何被创建,还有统计信息在性能调优中的重要性. 有2类统计信息,索引统计信息和列统计信息.索引统计信息是索引创建的一部分(建立索引会自动创建索引统计信息).在where条件列被引用或查询的group by子句里包含列,列统计信息都会由SQL Server自动创建. 有数据库属性设置里,可以设置数据库是否自动创建统计信

mysql监控、性能调优及三范式理解

原文:mysql监控.性能调优及三范式理解 1监控 工具:sp on mysql     sp系列可监控各种数据库 2调优 2.1 DB层操作与调优 2.1.1.开启慢查询 在My.cnf文件中添加如下内容(如果不知道my.cnf的路径可使用find / -name my.cnf进行查找): 在mysqld下添加 Log_slow_queries = ON  作用:开启慢查询服务 Log-slow-queries = /var/log/slowqueries.log 作用:慢查询日志存储路径.

性能调优:IO消耗分析

性能调优->如何分析io消耗 转载请注明出处:http://blog.csdn.net/supera_li/article/details/45225077 IO消耗分析示意图 对于io消耗,分文件IO和网络IO.文件IO主要是输入输出流与内存的消耗.网络IO一般是网卡的吞吐量,java程序一般不会产生网络IO消耗.原因是堆内存在网络IO之前,那么会提前爆掉.也就不存在网络IO的消耗了. 文件IO消耗 1.pidstat -d -t -p 查看线程IO消耗.该命令必须有SYSSTAT工具的支持,

深入理解Java虚拟机(jvm性能调优+内存模型+虚拟机原理)视频教程

14套java精品高级架构课,缓存架构,深入Jvm虚拟机,全文检索Elasticsearch,Dubbo分布式Restful 服务,并发原理编程,SpringBoot,SpringCloud,RocketMQ中间件,Mysql分布式集群,服务架构,运 维架构视频教程 14套精品课程介绍: 1.14套精 品是最新整理的课程,都是当下最火的技术,最火的课程,也是全网课程的精品: 2.14套资 源包含:全套完整高清视频.完整源码.配套文档: 3.知识也 是需要投资的,有投入才会有产出(保证投入产出比是

在SQL Server 2016里使用查询存储进行性能调优

作为一个DBA,排除SQL Server问题是我们的职责之一,每个月都有很多人给我们带来各种不能解释却要解决的性能问题. 我就多次听到,以前的SQL Server的性能问题都还好且在正常范围内,但现在一切已经改变,SQL Server开始糟糕, 疯狂的事情不能解释.在这个情况下我介入,分析下整个SQL Server的安装,最后用一些神奇的调查方法找出性能问题的根源. 但很多时候问题的根源是一样的:所谓的计划回归(Plan Regression),即特定查询的执行计划已经改变.昨天SQL Serv

服务器性能调优

转:http://blog.csdn.net/wj_j2ee/article/details/7987483 一 绪论 Linux性能监控之绪论篇性能调优的目的是找到系统的瓶颈,并且调节系统来设法消除这些瓶颈.我们在监控性能的时候重点在于监视一下子系统:1.CPU2.Memory3.IO4.Network 但这些系统都是彼此依赖,不能单独只看其中一个.当一个系统负载过重时往往会引起其它子系统的问题,比如说:->大量的读入内存的IO请求(page-in IO)会用完内存队列;->大量的网络流量会

性能测试分析与性能调优诊断--史上最全的服务器性能分析监控调优篇

一个系统或者网站在功能开发完成后一般最终都需要部署到服务器上运行,那么服务器的性能监控和分析就显得非常重要了,选用什么配置的服务器.如何对服务器进行调优.如何从服务器监控中发现程序的性能问题. 如何判断服务器的瓶颈在哪里等 就成为了服务器性能监控和分析时重点需要去解决的问题了. 1     服务器的性能监控和分析 1.1      Linux服务器的性能指标监控和分析 1.1.1       通过vmstat深挖服务器的性能问题 1.1.2       如何通过mpstat 分析服务器的性能指标

[大数据性能调优] 第二章:彻底解密Spark的HashShuffle

本課主題 Shuffle 是分布式系统的天敌 Spark HashShuffle介绍 Spark Consolidated HashShuffle介绍 Shuffle 是如何成为 Spark 性能杀手 Shuffle 性能调优思考 Spark HashShuffle 源码鉴赏 引言 Spark HashShuffle 是它以前的版本,现在1.6x 版本默应是Sort-Based Shuffle,那为什么要讲 HashShuffle 呢,因为有分布式就一定会有 Shuffle,而且 HashShu