SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践

摘要:
深入分析SQL Server性能调整执行计划第2节执行计划第一次练习前言:自从上一篇文章发表以来,我收到了朋友们的大量关注。图形执行计划中的每个图标都表示一个操作。在之前的执行计划中有两项操作。对于估计的执行计划,这个数字是优化器对执行计划中每个操作步骤进行成本分析的结果。在上图中,它指示了表扫描操作期间整个执行计划的第一步。

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践

前言:自从上一篇文章发出之后,收到了很朋友的关注。很多朋友要求多多实践,而不是纯粹的理论。确实,从打算出这个系列开始,我就本着实践的思想来进行的!同时,为了使得大家更好的理解、消化这些知识,我会定期的就所写内容进行在线的视频讲座,朋友们可以去参与这个小组:http://www.agilesharp.com/c/sqlprofiler.aspx

报名活动开始啦:http://www.agilesharp.com/Event.aspx/T-2

 

         议程如下:

         实践概述

         图形化执行计划实战

         执行计划信息解读

 

实践概述

         执行计划可以辅助我们写出高效率的T-SQL代码,同时也可以找出现有T-SQL代码的问题,还可以监控数据库!当然,最后如何使用执行计划还是取决于我们自己了,但是不管怎么样,我们首先学会解析执行计划中所包含的信息,最快的学习方法就是实践。下面,我们就从一个实践开始。

        为了使得大家易于理解,这里的例子不会太复杂,随着课程的不断深入,后续的示例也会越来越复杂。同时,如果大家也想跟着一起动手实践,那么希望朋友们安装SQL2005或更高版本,同时记得安装AdventureWorks数据库。下载地址为:http://msftdbprodsamples.codeplex.com

        另外,有一个需要注意的是,由于数据库中数据,操作和时间的关系,可能大家在运行脚本产生的执行计划和我这里不完全一样,这是没有任何问题的!

图形化执行计划实战

      下面我们正式进入要讨论的话题。

       首先,为了使得我们可以查看执行计划,最起码要确保我们在登录数据库的时候,要被授予权限,如下语句所示:

1.GRANTSHOWPLAN TO[username]

      为了将讨论集中在执行计划(估计执行计划和实际执行计划)上,我们这里这是运行一个比较简单的查询,如下代码所示:

1.SELECT* FROM[dbo].[DatabaseLog];

      

       下面,我们就来看看这个语句的估计执行计划,正如之前文章讲述的:估计执行计划是优化器使用了的元数据,成本分析算法等而产生的计划,这个计划是查询语句执前的一个分析!

显示估计执行计划

         我们可以采用以下几种方式显示估计执行计划:

               1.  点击Sql Server Studio工具栏上的按钮:  

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践第1张

              2.  在查询窗口右击鼠标,如下所示:

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践第2张

             3.  使用快捷键“CTRL + L”.

      对以上面的查询语句,显示的图形化的估计查询计划如下:

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践第3张

显示执行查询计划

       与估计执行计划不同,实际的执行计划不是优化器产生的,实际的执行计划是底层的存储引擎在执行时候产生的,这个计划中包含了大量的实际的底层数据和相关的信息。

       我们可以采用以下方式获得实际的执行计划,如下所示:

            1.  点击工具栏上面的按钮:

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践第4张

            2.  在查询窗口右击鼠标,如下:

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践第5张

            3.  快捷键“CTRL + M”

      上述查询的实际执行计划如下所示:

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践第6张

         大家初一看,以为两者没有区别,但是它们包含的数据信息很多是不一样的。

        下面,我们就开始对图形化的执行计划进行解读。

      

执行计划信息解读

         刚刚大家已经看了图形化的执行计划了,相关大家比较关心的问题有两个:如何解读执行计划中提供的各种信息;如何采用执行计划来进行性能调优。

 

         我们首先来看看第一个问题。

 

         一般而言,我们在阅读图形化的执行计划的时候顺序是这样的:从右向左,从下往上。也就说:sql执行的第一步就显示在执行计划的右下角。

         在图形化执行计划中的每一个图标,都表示一个操作,在之前的执行计划中就有两个操作。并且每个操作之前采用箭头连接起来,表明了数据流动的方向,其中箭头的粗细就反应了数据量的大小。

 

         另外,在每个操作下面都显示了一个百分比。

 

        对于估计执行计划而言,这个数字就是优化器对执行计划中每一个操作步骤进行成本分析后的结果。例外,在我们的例子中,整个查询最后会有两个操作会进行,Select和Table Scan,其中整个查询的成本将会落在Table Scan(整表扫描)上。

 

操作提示信息

         当我们把鼠标放在每个操作或箭头上面的时候,就会弹出更多的相关信息,我们下面就来具体的看一看。

         例如,当我们把鼠标放在执行计划的Select操作上面,显示如图:

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践第7张

        上面图中给出的信息非常清楚了,我这里只是解释一下“估计子树大小”。因为执行计划可以看出是sql语句的逻辑执行步骤,这个选项就告诉我们:在我们现在所看的这个操作步骤以及后面的所有步骤的开销是多少,是一个总计数字。

         如何朋友们还有有什么不清楚的,我们在后续将要展开的在线讲座中讲述!

        

         下面我们看看Table Scan的提示信息,如下图所示:

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践第8张

        虽然这个操作中包含的信息就非常的多了,但是却都很容易理解。

        这里要稍微重点提一下就是“已排序”。很明显,这个值告诉我们:Table Scan这个操作是建立在对数据排序的基础上的。例如,在查询语句中,有时候,我们写上order by语句,那么后续的很多的操作都是在已经排序的数据基础上进行,通过查看“已排序”是true还是false,我们就可以知道,查询语句内部是否自己进行了额外的排序操作(有时候,我们明明没有写order by,但是优化器却认为进行order by之后成本更小,这个时候我们就要注意了)。

 

       最后稍微的提一下“节点ID”,这个值就反应了操作在整个执行计划中的执行顺序,数字越小,说明越早被执行。在上图中,表明table scan操作时整个执行计划的第一步。

 

      为了使得大家更加的清楚,下面我们把之前的查询语句稍微的改下:

1.SELECT* FROM[dbo].[DatabaseLog] orderby  PostTime

 

      估计执行计划如下:

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践第9张

      我们查看提示信息,发现排序最先进行,然后再整表扫描。

SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践第10张

      文章首发站点:www.agilesharp.com IT创业产品互推平台

      今天就暂时到这里,下一篇,我们讲述相关的操作以及以文本和xml的形式查看执行计划。

报名活动开始啦:http://www.agilesharp.com/Event.aspx/T-2

免责声明:文章转载自《SQL Server性能调优之执行计划深度剖析 第二节 执行计划第一次实践》仅用于学习参考。如对内容有疑问,请及时联系本站处理。

上篇Kafka消费组(consumer group)在Django / DRF中正确处理日期时间/时区下篇

宿迁高防,2C2G15M,22元/月;香港BGP,2C5G5M,25元/月 雨云优惠码:MjYwNzM=

相关文章

SQL优化(Oracle)

(转)SQL优化原则一、问题的提出  在应用系统开发初期。因为开发数据库数据比較少。对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,可是假设将应用系统提交实际应用后,随着数据库中数据的添加。系统的响应速度就成为眼下系统须要解决的最基本的问题之中的一个。系统优化中一个非常重要的方面就是SQL语句的优化。对于海量数据,劣质SQL...

学习笔记:oracle学习一:oracle11g体系结构之服务器结构、数据字典

目录 1、服务器架构 1.1 系统全局区SGA 1.1.1 高速数据缓冲区(database buffer cache) 1.1.2 重做日志缓冲区(redo log buffer cache) 1.1.3 共享池(shared pool) 1.1.4 大型池(large pool) 1.1.5 Java池 1.1.6 流池 1.2 程序全局...

MySQL统计库表大小

统计每个库每个表的大小是数据治理的其中最简单的一个要求,本文将从抽样统计结果及精确统计结果两方面来统计MySQL的每个库每个表的数据量情况。 1、统计预估数据量 mysql数据字典库information_schema里记录了统计的预估数据量(innodb引擎表不准确,MyISAM引擎表准确)及数据大小、索引大小及表碎片的大小等信息。 如果想了解每个库及表...

浅谈SQL Server中的三种物理连接操作

本文转自:https://msdn.microsoft.com/zh-cn/library/dn144699.aspx 感觉写的很好,特此收录,以备自己和需要的朋友查看 简介 在SQL Server中,我们所常见的表与表之间的Inner Join,Outer Join都会被执行引擎根据所选的列,数据上是否有索引,所选数据的选择性转化为Loop Join,M...

YY 数据库平台化建设实践

钟建辉,YY基础运维经理,负责数据库及服务器基础运维工作,在数据库领域有超过10年的工作经验,见证了YY数据库平台化从”0”到”1”的整个历程,目前主要致力于推动YY数据库、服务器平台化建设。 以下为钟建辉老师演讲实录: 我的侧重点主要在运维DBA的角度介绍我们数据库系统。前面周老师就是研发的角度怎么看我们数据库平台系统。 一、YY数据库团队面临问...

mysql参数配置文件

(1)参数配置文件中的内容以键值对形式存在。 (2)如何查看键值对?show variables like '%name%';或者查看information_schema库下的global_variables视图; 如何修改呢? 1、innodb_buffer_pool_size=5G  2、客户端连接数据库的最大连接数:。通常,mysql的最大连...