set statistics time on的理解

本文详细介绍了 SQL Server 中 SET STATISTICS TIME 命令的使用方法及输出结果的意义,通过实际案例展示了如何开启和关闭该命令,并解释了 CPU 时间与占用时间的区别。

转载地址:http://www.studyofnet.com/news/568.html

本文导读:SET STATISTICS TIME 命令用来识别在SQL Server端的解析、编译和执行时间。这个时间不包括将数据传输到Client 端的时间。下面介绍SQL Server中set statistics time on的用法

一、set statistics time on的作用

显示分析、编译和执行各语句所需的毫秒数。

 

二、语法

SET STATISTICS TIME { ON | OFF }

注释

1、当 SET STATISTICS TIME 为 ON 时,显示语句的时间统计。一旦执行了上述命令,在整个会话期间,时间统计一直保持启用状态,直到执行 OFF 操作。

2、为 OFF 时,不显示时间统计。

2、SET STATISTICS TIME 的设置是在执行或运行时设置,而不是在分析时设置。

 

三、set statistics time on实例

 
SQL 代码   复制

 USE AdventureWorks;   
GO          
SET STATISTICS TIME ON   
GO   
SELECT *    
FROM Production.ProductCostHistory   
WHERE StandardCost < 500.00;   
GO   
SET STATISTICS TIME OFF;   
GO

 

输出结果

 
SQL 代码   复制

  SQL Server 分析和编译时间: 
   CPU 时间 = 15 毫秒,占用时间 = 104 毫秒。
SQL Server 分析和编译时间: 
   CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。

(4 行受影响)

SQL Server 执行时间:
   CPU 时间 = 171 毫秒,占用时间 = 1903 毫秒。
SQL Server 分析和编译时间: 
   CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。

 

四、set statistics time 的输出的意思

 

1、CPU时间 

这个值的含义指的是在这一步,SQLSERVER所花的纯CPU时间是多少。也就是说,语句花了多少CPU资源

 

2、占用时间 :

此值指这一步一共用了多少时间。也就是说,这是语句运行的时间长短,有些动作会发生I/O操作,产生了I/O等待,

或者是遇到阻塞、产生了阻塞等待。总之时间用掉了,但是没有用CPU资源。所以占用时间比CPU时间长是很正常的 ,但是CPU时间是

语句在所有CPU上的时间总和。如果语句使用了多颗CPU,而其他等待几乎没有,那么CPU时间大于占用时间也是正常的

 

3、分析和编译时间:

这一步,就是语句的编译时间。由于语句运行之前清空了所有执行计划,SQLSERVER必须要对他编译。

这里的编译时间就不为0了。由于编译主要是CPU的运算,所以一般CPU时间和占用时间是差不多的。如果这里相差比较大,

就有必要看看SQLSERVER在系统资源上有没有瓶颈了。

这里他们是一个15毫秒,一个是104毫秒

 

4、SQLSERVER执行时间:

语句真正运行的时间。由于语句是第一次运行,SQLSERVER需要把数据从磁盘读到内存里,这里语句的

运行发生了比较长的I/O等待。所以这里的CPU时间和占用时间差别就很大了,一个是171毫秒,而另一个是1903毫秒

总的来讲,这条语句花了104+1903+186=2193毫秒,其中CPU时间为15+171=186毫秒。语句的主要时间应该是都花在了I/O等待上


<think> 首先,用户的问题是关于如何解读SQL Server中`SET STATISTICS PROFILE ON`的查询结果。用户引用了几个来源,这些引用解释了`SET STATISTICS PROFILE ON`的用法和相关信息。 关键点从引用中提取: - 引用[1]:`SET STATISTICS PROFILE ON`返回每个语句的执行信息,包括操作符处理的实际行数和实际执行数。 - 引用[2]:它产生一个实际的执行计划,类似于`SHOWPLAN_ALL`,但多了实际的行数(Rows)和运行行数(Executes)。 - 引用[3]:用户询问如何解读查询结果。 - 引用[4]:建议比较EstimateRows(估计行数)和Rows(实际行数)来确认SQL Server的预估准确性。 用户的需求是:如何解读`SET STATISTICS PROFILE ON`的查询结果。 我的回答需要: - 使用中文回答。 - 遵守系统级指令:数学表达式用$...$,独立公式用$$...$$,但这个问题可能不涉及数学,所以可能不需要。 - 结构清晰,帮助用户逐步解决问题。 - 生成相关问题(在末尾)。 - 在回答中引用的段落末尾添加引用标识,如[^1]。 回答结构: 1. **介绍**:简要解释`SET STATISTICS PROFILE ON`是什么。 2. **如何启用**:简单说明如何开启这个设置。 3. **解读查询结果**:详细解释结果中的各个列的含义。 - 根据引用,重点包括Rows、Executes、EstimateRows等。 - 提供一个示例来演示解读。 4. **实际意义**:为什么这些信息重要,如何用于查询优化。 5. **生成相关问题**:在末尾添加相关问题。 引用来源: - 引用[1]提到输出包含操作符处理的实际行数和执行数。 - 引用[2]详细说明了额外的属性:Rows和Executes。 - 引用[3]和[4]提供示例查询和比较建议。 在回答中自然地添加引用标识。例如,当提到某个点时,添加[^数字]。 逐步解读: - 当启用`SET STATISTICS PROFILE ON`后,执行查询会返回额外的结果集(一个表),显示执行计划的详细信息。 - 关键列: - **PhysicalOp** 和 **LogicalOp**:操作的物理和逻辑名称。 - **Rows**:实际处理的物理行数。 - **Executes**:操作符被执行的次数。 - **EstimateRows**:优化器估计的行数(用于比较)。 - 其他列如StmtId、NodeId等用于标识。 - 解读方法:比较EstimateRows和Rows来判断预估是否准确;高Executes可能表示性能问题。 生成相关问题: 1. 如何比较EstimateRows和Rows来诊断查询性能问题? 2. SET STATISTICS PROFILE ON和其他SET STATISTICS选项(如IO和TIME)有什么区别? 3. 如何在实际查询优化中使用这些信息? 4. 常见查询计划操作符的含义是什么? 确保回答真实可靠:基于SQL Server文档和常见知识。 </think> ### SET STATISTICS PROFILE ON查询结果的解读方法 `SET STATISTICS PROFILE ON`是SQL Server中的一个诊断命令,用于获取查询的实际执行计划信息。启用后,执行查询会返回两个结果集:常规查询结果和一个额外的“执行配置文件”表。后者详细描述了查询的执行过程,包括操作符的实际处理行数、执行次数等关键指标,这对查询性能分析和优化至关重要[^1][^2]。下面我将逐步解释如何解读其查询结果。 #### 1. **开启SET STATISTICS PROFILE ON** 在执行查询前,运行以下命令启用该功能: ```sql SET STATISTICS PROFILE ON; GO -- 示例查询 SELECT DISTINCT ProductID, UnitPrice FROM SalesOrderDetail WHERE ProductID = 777; GO ``` 执行后,查询结果下方会附加一个表格形式的输出。该表格包含多列,我们需要重点关注几个核心列来解读执行计划。 #### 2. **关键列的含义及解读方法** 执行配置文件输出是一个表格,每行代表查询计划中的一个操作符(如索引扫描、键查找等)。以下是主要列的解释和如何解读: - **Rows**: 操作符**实际处理的物理行数**。这是最关键的指标之一,表示该步骤处理了多少行数据。例如,如果`Rows`值很高,可能表示该操作(如扫描)效率低下,需要优化索引[^2][^4]。 - *解读示例*:在`WHERE ProductID = 777`的查询中,如果`Rows`显示为500,说明该条件实际筛选了500行数据。 - **Executes**: 操作符**实际被执行的次数**。如果该值大于1,可能表示冗余操作或循环执行,常见于嵌套查询或JOIN操作中[^1][^2]。 - *解读示例*:在JOIN查询中,如果`Executes`为10,表示内表被扫描了10次,这可能导致性能瓶颈。 - **EstimateRows**: 优化器**预估的处理行数**(基于统计信息)。通过与`Rows`比较,可以判断优化器的预估是否准确。如果`EstimateRows`与`Rows`差异大(如预估100行,实际1000行),说明统计信息过时或查询条件选择性差,需要更新统计信息或优化查询[^4]。 - *解读示例*:引用[4]中的示例显示,比较`EstimateRows`和`Rows`是诊断预估错误的常用方法。 - **PhysicalOp** 和 **LogicalOp**: 分别表示**物理操作符**(如Index Scan、Hash Match)和**逻辑操作符**(如Inner Join、Aggregate)。这些列描述操作的类型。逻辑操作符表示优化器的意图,物理操作符表示实际执行方式。 - *解读示例*:`PhysicalOp`显示为"Index Scan"表示使用了索引扫描,而"Index Seek"更高效;如果显示"Table Scan",表示全表扫描,通常需要添加索引。 - **Argument**: 操作符的**详细信息**,如使用的索引名或过滤条件。这有助于识别具体执行对象。 - *解读示例*:`Argument`显示为`[PK_SalesOrderDetail]`时,表示操作基于主键索引。 - **NodeId** 和 **Parent**: 表示操作符在**执行计划树中的位置和层级**。`NodeId`是当前节点ID,`Parent`是其父节点ID(根节点Parent为0)。这用于理解操作符的依赖关系。 - *解读示例*:一个有`Parent`为1的节点,表示它是ID=1的节点的子操作(如JOIN的子查询)。 #### 3. **解读步骤示例** 假设执行配置文件输出如下片段(简化示例): | NodeId | Parent | LogicalOp | PhysicalOp | EstimateRows | Rows | Executes | Argument | |--------|--------|---------------|---------------|--------------|------|----------|-------------------| | 1 | 0 | Inner Join | Hash Match | 1000 | 1200 | 1 | NULL | | 2 | 1 | Index Scan | Index Scan | 500 | 600 | 1 | [IX_ProductID] | | 3 | 1 | Key Lookup | Key Lookup | 500 | 600 | 1 | [PK_SalesOrder] | - **整体解读**:这是一个JOIN查询(NodeId 1),实际处理1200行(高于预估的1000行),执行一次。其子操作包括索引扫描(NodeId 2)和键查找(NodeId 3),各处理600行。 - **关键分析**: - `EstimateRows` (1000) 与 `Rows` (1200) 差异较大,表示统计信息可能需要更新[^4]。 - 所有`PhysicalOp`显示高效操作(Hash Match、Index Scan),但如果`PhysicalOp`出现"Table Scan",则需优化索引。 - `Executes`均为1,表示无冗余执行。 #### 4. **实际应用与优化意义** - **性能诊断**:比较`Rows`和`EstimateRows`可以识别预估错误,这是查询变慢的常见原因(如引用[4]所述)。高`Rows`或高`Executes`的操作符通常是优化重点。 - **优化建议**: - 如果`Rows`显著大于`EstimateRows`,运行`UPDATE STATISTICS`更新统计信息。 - 如果`PhysicalOp`包含扫描操作,考虑添加缺失索引。 - 高`Executes`可能提示重构查询,避免嵌套循环[^2][^3]。 - **与其他命令对比**:`SET STATISTICS PROFILE ON`提供实际数据(实际行数),而`SET SHOWPLAN_ALL ON`只显示预估计划,不包含实际执行细节[^2]。结合`SET STATISTICS IO ON`(查看I/O开销)和`SET STATISTICS TIME ON`(查看编译/执行时间)能全面分析性能[^2]。 通过以上解读,您可以快速定位查询瓶颈。例如,引用[3]中的示例通过`SET STATISTICS PROFILE ON`分析了`WHERE`条件的实际影响,帮助优化筛选逻辑。 ### 相关问题 1. 如何结合SET STATISTICS PROFILE ONSET STATISTICS IO ON进行全面的查询性能分析? 2. 当EstimateRows和Rows差异较大时,有哪些具体方法来更新统计信息或优化查询? 3. SET STATISTICS PROFILE ON在诊断嵌套查询或存储过程时的特殊应用场景是什么? 4. 常见的执行计划操作符(如Hash Match、Index Seek)如何影响查询效率,如何优化它们?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值