《高性能SQL调优精要与案例解析》一书谈主流关系库SQL调优（优化TUNING）技术精髓之—

《高性能SQL调优精要与案例解析》中，主要以Oracle为样本讲解了SQL调优（优化&TUNING），其中，前面博文中本人也说到，就SQL调优的思路、方法和步骤来说，各关系库几乎是一样的，差别只是具体的形式、命令等，为解除各位读者对《高性能SQL调优精要与案例解析》一书中内容的疑惑，更重要的是，希望各位读者能更好的理解和领会《高性能SQL调优精要与案例解析》一书中的精髓，本人尽量会在博客中多写一些与该书内容相关内容。下面，我们就简要介绍一下各主流关系库中，SQL语句执行计划获取的方法及相关指标的理解。

1、Oracle

因《高性能SQL调优精要与案例解析》一书以Oracle为样本编写，该书中通过较大篇幅详细介绍了获取SQL语句执行计划的各种方法，这里不再一一赘述，为了让读者能更好的阅读和理解该博文，下面还是简要列出Oracle中获取SQL语句执行计划的各种方法。

1）GUI工具：就是通过各种流行的开发或管理工具获取SQL语句执行计划。

2）autotrace功能：该工具为Oracle本族产品，通过该产品，可以很方便的获取SQL语句的执行计划，结果集和性能统计数据。

3）DBMS_XPLAN包：该包为Oracle提供的用于获取SQL语句执行计划的内置包，该包功能强大，可以完成执行计划相关的各种人为，可谓Oracle中最强大、最专业的执行计划相关的工具。

4）SQL查询方法：通过用SQL语句查询系统视图或专用表，获取SQL语句执行计划。

5）跟踪方法：通过启用Oracle中的相关跟踪特性，以对SQL语句的内部行为进行记录，最后生成包含执行计划相关信息的跟踪文件。

2、MSSQL

SQL Server，世界三大商用关系库之一，俗称MSSQL，其在数据库商用关系库市场上也拥有相当的占有率。作为微软公司的拳头产品，其优化器方面的功能还是相当强大的，除了拥有完备的组件、模型、算法及众多的操作，其也提供了多种方便获取SQL语句执行计划的方法和途径，同时，其执行计划也提供了非常丰富的内容和信息，从某种程度上讲，MSSQL执行计划中暴露的信息量，比Oracle还要丰富和详细。下面，我们就分别看看MSSQL中获取SQL语句执行计划的方法。

1）管理工作室（management studio）：该工具是MSSQL提供的本族管理GUI工具，该GUI工具功能非常强大，感觉几乎无所不能，界面也非常友好和易操作，尤其对初学或非专业人士更加方便，当然，即使是资深的专业人士，有时也会经常会用并依赖该工具，该工具与Oracle的EM GUI管理工具非常类似，只是，个人感觉其比Oracle的EM功能更全面、体验更好些。言归正传，我们还是继续谈SQL语句执行计划的获取，通过该工具，我们很容易获取SQL语句的执行计划，该执行计划为图形执行计划，也就是将SQL语句的执行计划通过图形的方式展示出来，这点，有点类似《高性能SQL调优精要与案例解析》一书中，通过GUI工具获取的SQL语句执行计划类似，只是，感觉MSSQL的管理工作室生成的图形执行计划更加友好、专业，信息量也更大。图形执行计划中，每个图标代表执行计划中每个节点中的操作，而图标间的箭头线，则代表数据在各节点间的流向。

在该图形执行计划中，我们可以点击其中的每个图标或箭头线，都会出现相应的工具提示（Tooltips）窗口和属性窗口，这两个窗口中，都包含了执行计划每个节点操作或数据流的详细信息，依次，我们就可以对执行计划进行分析。值得提出的是，该图形执行计划虽然是一张漂亮而直观的大图，对初学者甚至资深人士浏览起来非常方便，然后，对有些较为复杂的SQL语句来说，这张图有时因为变得非常大，而浏览时不得不频繁的缩放或滚动来进行浏览，这可能会存在多少的不方便。此外，该图形执行计划还可以保存成一个.sqlplan文件，该文件实际以XML格式保存，因此，除了可以作为图形执行计划进行加载和浏览，还可以以XML格式进行阅读。

2）命令行（文本格式执行计划）：通过相关命令行，MSSQL也可以提供文本格式的执行计划，该执行计划通过缩进和竖线来表达其中各节点间的父子关系，这点和Oracle中，通过非GUI工具获取的执行计划计划相同，阅读方法当然也计划完全相同，MSSQL中常用的获取SQL语句文本执行计划的命令行如下所示。

SET SHOWPLAN_TEXT ON：通过该命令行，就可以获取SQL语句的文本执行计划，但只获取执行计划。

SET SHOWPLAN_ALL ON：通过该命令行，除了可以获取SQL语句的文本执行计划外，还会获取图形执行计划中工具提示和属性窗口中包含的各节点相关的详细信息。

3）命令行（XML格式执行计划）：通过相关命令行，MSSQL2005及后续版本可以获取XML格式的执行计划，作为IT人士，想必大家都很熟悉XML格式，通过它能比较方便的表达执行计划各节点的父子关系，而且，上面我们也提到了，XML格式的执行计划可以通过管理工作室工具打开为图形格式的执行计划，图形格式的执行计划也可以保存为XML格式的文件格式。XML格式的执行计划集图形和文本格式很多优点于一身，XML格式执行计划不但可以非常方便的通过程序对计划进行处理，同时，还可以很方便的存储于数据库的相关字段中。

以上简要介绍了MSSQL中获取SQL语句执行计划的方法，鉴于MSSQL各节点操作中包含大量的内容和信息，同时，这些信息的字解释性也比较强，大家可比较方便的济宁阅读和分析，或者参考官方或其他相关资料，这里不再对这些信息进行一一解释，或许如果有时间，可以另开博文进行详细论述。

3、Mysql

目前，Mysql在互联网行业可谓大行其道，但坦率的讲，其优化器表现并不像其他方面那么优越，相比商业库，甚至某些开源库来说，Mysql优化器的功能还有待增强和完善，输出的内容和信息也比较有限和晦涩难懂。下面，我们就对这一开源库获取SQL语句执行计划的方法进行说明和讲解。

1）explain命令：目前，Mysql主要靠该命令来获取SQL语句的执行计划，虽然，该命令存在一些限制（例如：Mysql5.6版本之前，不能获取DML语句执行计划。）和时有不准确的现象发生，但是，目前也没有其他更好的可用信息，至少，我们通过该命令获取的执行计划，可以分析和研究Mysql优化器内部解析SQL语句的过程，从而，发现SQL语句存在的性能问题，进而想办法解决这些问题。

该命令语法：

mysql> explain select ... from ... where...;

输出指标简要说明：

id列：该列总是包括一个数字，该数字标识计划中的该行所属于的select语句。如果语句中没有子查询（SUBQUERIES）或UNIONS等，而只有一个SELECT语句，那么，该id列总是显示1。

select_type列：该列显示计划中该行代表简单或复杂SELECT语句。如果是简单SELECT，则语句中不包含任何SUBQUERIES或UNIONS；否则，计划中最外面部分显示为PRIMARY，其他部分显示为：SUBQUERY（一个包含于SELECT-LIST中的子查询所包含的SELECT语句）；DERIVED（包含在FROM子句子查询中的SELECT语句）；UNION（一个包含UNION的语句中第二个后的SELECTS都显示为UNION，而语句中第一个SELECT则显示为PRIMARY，如果该包含UNION的语句位于FROM子句中，则，该语句中第一个SELECT显示为DERIVED）；UNION RESULT（从UNION匿名临时表中获取UNION最终结果则显示为UNION RESULT）；DEPENDENT（表示该SELECT依赖外查询的数据）；UNCACHEABLE（表示该SELECT结果因某种因素不能被缓冲）；

table列：该列显示计划中该行正存取的表或别名。通过从上向下读取该列，可以看出各表或别名间的连接顺序。当FROM子句中包含子查询时，该列将显示为DERIVEDN，其中，N为子查询的id列值，这里，N参考explain输出中的下面一行；而当FROM子句中包含UNION时，计划中UNION RESULT行的该table列，将包含参与UNION操作的所有id，该行总是参考explain输出中其前面的行。

type列：该列显示对数据行的存取路径。主要有如下几种方法：ALL（全表扫描）；index（全索引扫描，即依次扫描索引中的所有键值，输出结果以键值顺序排列）；range（范围索引扫描，谓词中包含in,or,between，>,>=,<,<=等操作符时，计划中会出现该列值）；ref（单值索引扫描，这了需要注意的是单值+范围扫描）；ref_or_null（ref值的变种，单值或null索引扫描）；eq_ref（等值索引查找，一般发生于主键索引或唯一索引）；const&system（通过常数转换来消除部分查询的优化方法）；null（MYSQL在优化阶段完成避免存取表或索引）。

possible_key列：该列显示可能会被查询用到索引。

key列：该列显示决定用哪个索引来优化存取路径。

key_len列：该列显示被用索引键值的字节数。

ref列：该列显示之前行源中哪些列或常数被用于前述key列中索引键值的查找。

rows列：该列显示被评估输出的数据行数。

filtered列：该列显示满足某个谓词条件的数据行的悲观评估百分比，该列出现于mysql5.1版本的explain extended命令。

extra列：该列显示不适于放在前述各列的额外信息。主要会有如下一些列值：using index（表示发生一个覆盖索引，以避免回表操作）；using where（表示对存储引擎读取的数据进行读取后过滤）；using temporary（表示会用临时表对数据进行排序）；using filesort（表示不是通过索引，而是通过外部操作对数据进行排序，这里，并不能分辨是否发生了内存还是磁盘排序）；range checked for each record(index map:N)（表示没有合适的索引，需对索引进行重新评估，这里，N为possible_keys列中的冗余索引）。

2）GUI工具：通过其他专业工具或GUI工具可以获取图形执行计划，例如：percona工具包中的pt-visual-explain和toad等。

由上可见，虽然mysql生成执行计划时用到了统计数据，但在执行计划中并未暴露成本相关的信息（评估数据行除外）。

4、Postgresql

该开源数据库产品，习惯的被人称作“免费版的Oracle”，这一被人们俗称来的盛誉绝非浪得虚名，从内部机制到功能特点，再到具体的命令语法，无不体现了这一俗称的名副其实。看过PG源码的同学们无不称赞其代码风格的优雅，而这一优雅特点也体现在该产品的方方面面，因为本帖主要是为了讨论执行计划，我们不得不说，PG的执行计划也体现了优雅，这和Oracle有点类似，除了优雅，PG的执行计划这块同时还体现了简洁和强大，下面，我们就来欣赏PG执行计划的优雅。

1）explain 命令：该命令产生文本形式的执行计划，同时，在使用该命令获取执行计划时，我们有可以有两个选项，具体如下：

explain SQL语句：该选项只产生执行计划，并不实际执行后面的SQL语句；

explain analyze SQL语句：该选项除了产生执行计划，还会实际执行后面的SQL语句，同时，还会给出执行该SQL语句时的相关信息，因此，我们在分析DML类型的SQL语句时，一定要注意这点。

此外，PG的文本执行计划和Oracle及SQL Server的文本执行计划非常相似，甚至会给人一种更加的简洁和强大的感觉，其执行计划也是由分层缩进的各个节点及操作组成，下面，我们来分别看看PG执行计划中比较重要的一些信息。

首先，我们看到的是计划中预计成本部分：

cost=c1..c2：每个节点中cost项中第一个数字（c1，可为小数）为该节点预计的启动成本；而第二个数字（c2，可为小数）为完成该节点预计所需要的成本。

rows=r1：每个节点中预计产生的数据行（r1，为整数）。

width=w1：每个节点中输出数据行的预计平均宽度（w，为整数，单位为字节）。

其次，我们看到的是计划中计划成本部分：

acual time=t1..t2：每个节点中actual time项中第一个数字（t1,可为小数）为该节点实际的启动成本；而第二个数字（c2，可为小数）为完成该节点所实际消耗的成本。

rows=r2：每个节点中实际产生的数据行（r2，为整数）。

loops=l：相关节点发生的实际操作数（l），值得提出的是，当相关节点的l值大于1时，其中包含相关节点的actual time及rows等指标为每次操作的值，而非总值。

此外，explain命令还提供verbose等更多选项，具体大家可以查阅相关文档，此处，不再赘述。

2）GUI格式工具：当我们查看比较复杂和冗长的执行计划时，尤其是对于入门或业余人员来讲，这将是非常繁琐的事情，很多时候会看的头晕眼花，这不能怪他们，因为，这种仅仅靠缩进格式来表示各节点层级关系的格式，有时也很容易让经验丰富的老手或专业人员迷惑，为了解决这个问题，图形执行计划就排上了用场，目前，能给出PG图形格式执行计划的工具不是很多，但还是有一些的，例如：pgadmin等。可惜的是，本人从来没找到toad for postgresql版本，如果哪位同学知道或有，麻烦共享下，先谢谢了。

作为开源关系库，优化器这块来说，个人认为PG比MYSQL更成熟，也更强大，这点来说，几乎可以和成熟的商业库媲美。

关于该博文到此为止，以期抛砖引玉，感兴趣的同学具体可以查阅相关文档，或者与本人保持沟通和交流，共同进步，如果时间允许，本人也会及时和大家探讨。

值得提出的一点是，鉴于本人最近事情比较繁多，空闲时间也比较少，以致于该博文今天才能完成，还请各位同学理解，谢谢各位。

《高性能SQL调优精要与案例解析》一书谈主流关系库SQL调优（优化TUNING）技术精髓之——执行计划获取及理解相关推荐

SQL Server 执行计划(8) - 使用 SQL 执行计划进行查询性能调优
在本系列的前几篇文章(见底部索引)中,我们介绍了SQL 执行计划的多个方面,我们讨论了执行计划是如何在内部生成的,不同类型的计划,主要组件和运算符以及如何阅读和分析使用不同工具生成的计划.在本文中,我 ...
浅析SQL SERVER执行计划中的各类怪相
在查看执行计划或调优过程中,执行计划里面有些现象总会让人有些疑惑不解: 1:为什么同一条SQL语句有时候会走索引查找,有时候SQL脚本又不走索引查找,反而走全表扫描? 2:同一条SQL语句,查询条件的 ...
数据库sql优化总结之5--数据库SQL优化大总结
数据库SQL优化大总结小编最近几天一直未出新技术点,是因为小编在忙着总结整理数据库的一些优化方案,特此奉上,优化总结较多,建议分段去消化,一口吃不成pang(胖)纸一.百万级数据库优化方案 1.对 ...
oracle 重设基线,Oracle SQL执行计划基线总结（SQL Plan Baseline）
一.基础概念 Oracle 11g开始,提供了一种新的固定执行计划的方法,即SQL plan baseline,中文名SQL执行计划基线(简称基线),可以认为是OUTLINE(大纲)或者SQL PRO ...
oracle cpu基线,Oracle SQL执行计划基线总结（SQL Plan Baseline）
一.基础概念 Oracle 11g开始,提供了一种新的固定执行计划的方法,即SQL plan baseline,中文名SQL执行计划基线(简称基线),可以认为是OUTLINE(大纲)或者SQL PRO ...
Sql Server之旅——第十一站简单说说sqlserver的执行计划
原文:Sql Server之旅--第十一站简单说说sqlserver的执行计划我们知道sql在底层的执行给我们上层人员开了一个窗口,那就是执行计划,有了执行计划之后,我们就清楚了那些烂sql是怎么 ...
Sql Server之旅——第十站简单说说sqlserver的执行计划
我们知道sql在底层的执行给我们上层人员开了一个窗口,那就是执行计划,有了执行计划之后,我们就清楚了那些烂sql是怎么执行的,这样就可以方便的找到sql的缺陷和优化点. 一:执行计划生成过程说到执 ...
MySQL- SQL执行计划统计SQL执行每阶段的耗时
文章目录生猛干货官方文档某些SQL查询为什么慢 MySQL处理SQL请求的过程查询缓存对SQL性能的影响 SQL预处理及生成执行计划造成MySQL生成错误的执行计划的原因如何确定查询各个阶 ...
map语法获取index_MySQL SQL语法优化——使用Explain查看执行计划
夜深,最近在写SQL优化的一些文章,看到私聊中,有很多人在问如何判断是否需要优化或者是如何查看MySQL执行计划,本文简要介绍一下MySQL EXPLAIN命令. EXPLAIN命令是查看优化器如何决 ...

《高性能SQL调优精要与案例解析》一书谈主流关系库SQL调优（优化TUNING）技术精髓之——执行计划获取及理解

《高性能SQL调优精要与案例解析》一书谈主流关系库SQL调优（优化TUNING）技术精髓之——执行计划获取及理解相关推荐

最新文章

热门文章