Oracle看执行计划的方法：
1、从上往下，第一个没有子节点的步骤先执行。（这里尤其要注意，很多人都单纯的说“缩进最多的第一个执行”，这句话并不严谨）
2、对于兄弟节点，运用第一点，即靠上的节点先执行。
3、所有兄弟节点执行完以后，执行父节点。
postgresql执行计划怎么看
注：
从下到上：每个箭头表示1个节点。上一个节点的输入信息来自于它的下一个节点，所以需要从最下面开始分析，依次读到最顶层。
从里往外：由于上层结果是下层结果的输出，所以在理清层次结构后，需要先分析最里层，再依次往外分析。
同层的由上至下
简介
执行计划功能展示了SQL在执行的过程中走向、成本以及命中情况。主要作用于SQL调优，输出SQL执行的详细信息，有利于调优人员及时分析性能下降原因。
目录
-
语法
1.1. 参数选项 -
查看执行计划
2.1. 整体结构解析
2.2. 各个节点说明
① 扫描节点
② 连接节点
③ 物化节点
④ 控制节点
⑤ 并行节点
2.3. 参数输出说明
costs
analyze
verbose
buffers -
优化建议
-
语法
EXPLAIN [statement]
EXPLAIN [option] [statement]
EXPLAIN [all_option] [statement]
1.1. 参数选项
analyze
-执行真实的SQL，除估算成本外，额外输出一项实际结果
verbose
-输出每个结点的详细信息
costs
-输出估算成本(默认开启)
buffers --(前提：必须打开analyze)
-输出缓存使用信息命中率、脏数据、写，包含：共享块、本地块、临时块
format { text | xml | json | yaml }
-指定输出格式
若想查询DDL真实语句成本，可以利用事务回滚方法来使用执行计划。例如：
–开始事务
BEGIN;
–DDL语句执行查询计划
EXPLAIN ANALYZE UPDATE [table] SET id = id + 1;
–回滚事务
ROLLBACK;
事务回滚后并不会更新真正的数据，这样就能达到既想查看DDL语句的真实成本，又不会改变数据的好处。
- 查看执行计划
执行计划输出结构示意图：
2.1. 整体结构解析
执行计划的结构是怎样的？
按树形结构划分，每层分支用节点来表示，每个结点表示SQL在这一阶段做了什么。
红框表示第1层，蓝框表示第2层，绿框表示第3层，黄框表示第4层。
每一层都标识了扫描方式、估算成本、输出字段、内存命中。
怎么查看执行计划的结构？
从下到上：每个箭头表示1个节点。上一个节点的输入信息来自于它的下一个节点，所以需要从最下面开始分析，依次读到最顶层。
从里往外：由于上层结果是下层结果的输出，所以在理清层次结构后，需要先分析最里层，再依次往外分析。
例如：最里层的启动成本是0.00，结束成本是10.00；那么上一层可能就是启动成本从10.00开始，结束成本大于10.00。以下示意图中蓝框就是最好的例子：
红框：每个节点的开头说明
HashAggregate：表示走的hash聚合函数
Seq Scan：表示全部扫描
蓝框：该节点的估算成本
cost=1.92…1.95：表示启动成本1.92，结束成本1.95
rows：该语句返回的行数
width：该行的平均字节数
绿框：该节点的真实成本
time=0.087…0.093：表示启动成本0.087，结束成本0.093
rows：该节点返回的行数
loops：该节点循环次数
其他：该节点的详细信息
Output：该节点输出的sql语句
Batches：该节点内存使用大小
Buffers：内存命中率
简单说明
QUERY PLAN
HashAggregate (cost=1.92…1.95 rows=3 width=21) (actual time=0.100…0.102 rows=2 loops=1)
‘hash聚合扫描’ ‘(估算成本=启动成本…结束成本 , 执行SQL返回的行数 , 每行平均字节数)’ ‘(实际成本)’
Output: count(*), “position”
‘表示该节点执行的字段’
Group Key: pay_scale.“position”
‘表示该节点执行的字段’
Batches: 1 Memory Usage: 24kB
‘表示该节点内存使用大小’
Buffers: shared hit=7 read=10
‘表示共享内存中有7个命中块，10个未命中(可能在系统缓存中命中的)’
2.2. 各个节点说明
① 扫描节点
顺序扫描（seq scan）
控制参数：enable_seqscan = on
解释说明：根据实际的数据存取顺序，连续扫描所有数据。（多用于无索引的情况下）
适用情况：
一般为数据量小、且选择率高的表。
1000条数据以下，select 查出结果大于500条
索引扫描（Index scan）
控制参数：enable_indexscan = on
解释说明：根据查询条件扫描索引。因为索引是有序的，所以采用对半查找方式，快速找到符合条件的索引数据。再过滤条件和索引键值进行比较。
适用情况：
一般数据量大，但选择率较低的表。
1w条数据以上，select 查出结果低于实际条数的20%。
注意情况：
如果索引条件不存在（选择率非常高），性能会严重下降，甚至不如全表扫描。
位图扫描（Bitmap scan）
控制参数：enable_bitmapscan = on
解释说明：
1、先通过Bitmap Index Scan索引扫描，在内存中创建一个位图表，每个bit表示一个与过滤条件有关的页面（此页面有可能数据为1，不可能为0）。
2、再通过Bitmap Heap Scan表扫描，在内存中创建好的位图表指针对应的页面进行顺序扫描，排除不符合的记录，返回需要的结果。
适用情况：
列中含有重复值。
查询中包含and、or等范围性查找。
TID扫描（TID Scan）
控制参数：enable_tidscan = on
解释说明：根据数据实际存储位置的ctid进行扫描，获取元组。通过隐藏字段ctid扫描时标记数据位置的字段，通过这个字段来查找数据（速度较快）
适用情况：
where条件中带ctid的表。
覆盖索引扫描（Index Only Scan）
控制参数：enable_indexonlyscan = on
解释说明：允许直接从索引得到元组。覆盖索引扫描要求查询中的某个表，所需要数据均可从这张表的同一索引的索引页面中获得。
适用情况：
更新少的表
其他扫描节点
Sample Scan
数据取样功能，支持查询返回取样数据。
当前只在常规表和物化视图上接受tables ample子句。
Subquery Scan
以另一个查询计划树（子计划）为扫描对象进行元组扫描，其扫描过程最终被转换为子计划的执行。
主要包含：exists、in、not in、any/some、all。
Function Scan
扫描对象为：妇女会元组集的函数。
该节点在Scan的基础上扩展定义了function列表字段，存放Function Scan涉及的函数，以及funcordinality字段，是否返回结果加上序号列。
Valies Scan
values计算 由值表达式指定一个行值或一组行值。
常见的：把它用来生成一个大型命令内的常量表，但是它也可以被独自使用。
CTE Scan
with提供了一种方式来书写大型查询中使用的辅助语句，这些语句通常被称为公共表达式或CTE，它可以被看成是被定义在一个查询中存在的临时表。
with子句中的每个辅助语句可以是：select、insert、update、delete。
with子句本身也可以被附加到一个主语句，主语句也可以是select、insert、update、delete。
WorkTable Scan
它与Recursive Union共同完成递归合并子查询。
Foreign Scan
扫描外部表，用于fdw或dblink和外部数据的交互情况。
Custom Scan
自定义扫描接口
② 连接节点
嵌套循环连接（Nest Loop join）
控制参数：enable_nestloop = on
解释说明：扫描每条外表数据（m条），再与内表中所有的记录（n条）去连接。时间复杂度为：m * n。
适用情况：数据量小的表。
哈希连接（Hash join）
控制参数：enable_hashjoin = on
解释说明：对内表建立hash表，扫描所有内表数据到各个hash桶；再建立hash桶逐个扫描外表每一行，对外表数据进行hash到某个桶，再与这个桶里的数据进行连接。
适用情况：数据分布随机，重复值不多的表。
归并连接（Merge join）
控制参数：enable_mergejoin = on
解释说明：先对两张表排序，再做连接。
适用情况：两张表的数据都是有序的。
③ 物化节点
说明：物化节点是一类可缓存元组的节点。在执行过程中，很多扩展的物理操作符需要先获取所有元组后才能操作，这时就需要用物化节点将元组缓存（例如：聚合函数、无索引的排序）。
物化节点（Material）
控制参数：enable_material = on
解释说明：用户缓存子节点结果。对于需要重复多次扫描的子节点，可以减少执行的代价。
适用情况：结果在子查询中会被多次使用。
分组节点（3种情况）
1、Hash Aggregate
控制参数：enable_hashagg = on
解释说明：通过hash算法，把相同的值hash到同一桶中，再求聚集。
适用情况：数据无序的表。
2、Group Aggregate
解释说明：通过排序的方式进行分组，再求聚集。
适用情况：数据有序的表。
3、Aggregate
解释说明：执行含有聚集函数的group by操作，其中有3种策略：
Plain：不分组的聚集计算。
Sorted：下层节点提供排好序的元组（类似group方法）。
Hash：先对下层节点提供的末排序元组进行分组，再计算。
适用情况：含有聚集函数的group by操作。
排序节点（Sort）
控制参数：enable_sort = on
解释说明：对数据进行排序。
适用情况：输出结果是有序的情况。
去重节点（Unique）
解释说明：对下层节点返回已排序的元组进行去重。
适用情况：查询中带distinct关键字（当要求去重的属性被order by子句引用时，一般会使用该节点）。
其他物化节点
Window Agg
窗口函数
T_SetOp
setop语法节点
Lock Rows
使用锁定子句（for update、for share）
Limit
使用limit时的节点
④ 控制节点
BitmapAnd / BitmapOr节点
解释说明：这两个节点实现了2个或多个位图的and和or运算（将产生每一个位图的子计划放在一个链表中，在执行过程中先执行子计划节点获取位图，再进行and / or操作）。
适用情况：2种节点都是位图类型，用于位图计算。
Result节点
解释说明：执行计划不需要扫描表，执行器会直接计算select的投影属性，或使用values子句构造元组。
适用情况：针对那些不扫描的查询，用来优化包含仅需计算一次的过滤条件。
Append节点
解释说明：该节点会逐个处理这些子计划，当一个子计划返回所有结果后，会接着执行链表中的下一个子计划，直到全部执行完。
适用情况：用于处理包含一个或多个子计划的链表。
Recursive Union节点
解释说明：对节点递归进行处理。
适用情况：用于处理递归定义的union语句。
⑤ 并行节点
并行全表扫描（Parallel SeqScan）
当表数据量大、选择率低时，自动使用并行。
当表数据量大、选择率高时，不自动使用并行（大于50%）。
并行hash（Parallel Hash）
例如使用hash join
每个worker都是先扫描小表score计算hash，再并行扫描大表，最后做hash。将数据汇总到gather节点合并最终结果集。
并行嵌套（Parallel NestedLoop）
支持并行嵌套查询
如果不开启并行，普通的hash join性能会比开启低很多。
也支持其他并行
Gather / Gather Merge
并行聚集（Partial / Finalize Aggregate / HashAggregate / GroupAggregate）
并行排序（Gather Merge）
并行B-Tree索引扫描（B-tree Index Scan）
并行Bitmap扫描（Bitmap Heap Scan）
并行Append（Parallel Append）
并行Union（Parallel Union）
开启并行的参数
max_worker_processes（默认8）
OS支持的最大后台进程数
max_parallel_workers（默认8）
最大并行worker数
max_parallel_workers_per_gather（默认2）
最大并行执行worker数
max_parallel_maintenance_workers（默认2）
最大并行维护worker数
它们之间的配置关系：
以 max_worker_processes 为主配置
max_parallel_workers 不能超过主配置数量
max_parallel_workers_per_gather 和 max_parallel_maintenance_workers 相加的值也不能超过主配置数量
并行的触发条件
表
表的存储空间至少大于 min_parallel_table_scan_size（默认 8MB）
索引
索引的存储空间至少大于 min_parallel_index_scan_size （默认512KB）
查询某张表的索引大小
SELECT pg_size_pretty( pg_relation_size(’[表名]’));
并行注意项
在开启并行时，并不是所有的SQL都适合开并行，也并不是并行越多性能就越好，每条SQL都有适合自己的worker数，需要考虑开启并行后对系统开销成本计算。
如果cpu、共享内存、worker进程等资源是整个数据库共享。一个select如果消耗了大量的资源（比如开启了64个worker），其他会话能够申请的资源会变得有限，这一行为在OLTP事务应用中尤为重要。所以需要将worker设置为合理的范围。
2.3. 参数输出说明
postgresql的执行计划是以树形的方式输出该SQL的执行顺序，树形的呈现方式就是以节点呈现，而每个结点输出的详细信息由参数控制。
costs
costs主要输出执行计划的估算成本，而不是实际成本
cost=0.00…1.60：表示启动成本0.00，结束成本1.60
rows：该语句返回的行数
width：该行的平均字节数
计算估算成本的参数分别有：
seq_page_cost：全表扫描的单个数据块代价因子。
random_page_cost：索引扫描的单个数据块代价因子。
cpu_tuple_cost：处理每条记录的CPU开销代价因子。
cpu_index_tuple_cost：索引扫描时，每个索引条目的CPU开销代价因子。
cpu_operator_cost：操作符或函数的开销代价因子。
analyze
（这里手动把costs关了，因为它是默认打开的，主要为了展示analyze的输出结果）
analyze主要输出真实的成本（真正的去执行了这条SQL语句）
time=0.010…0.013：表示启动成本0.010，结束成本0.013
rows：该节点返回的行数
loops：该节点循环次数
Planning Time：计划执行的时间
Execution Time：实际执行的时间
如果不想让该SQL执行成功，可以利用事务回滚
verbose
verbose用于输出该节点执行的事情
buffers
buffers用于输出该节点的缓存命中率，前提是必须开启analyze
hit：该节点shared_buffer命中的page数量。
read：该节点shared_buffer没有命中的page，但可能在系统缓存中命中。
dirtied：该节点shared_buffer中出现的脏块。
written：该节点写入磁盘的page。
shared hit blocks（共享块）：例如 表、索引、序列的数据块。
local hit blocks（本地块）：例如 临时表、索引的数据块。
temp read blocks（临时块）：例如 排序、hash、物化节点。
- 优化建议
（来源于postgresql官方文档）
扫描节点优化建议
过滤条件尽量提早使用。
过滤性越高的字段靠前，过滤性低的字段靠后（id1 < 100 and di2 < 10)。
核心SQL可以考虑采用"覆盖索引"方式，确保尽可能高效。
多SQL总和考虑重复利用索引。
不干扰过滤的前提下，order by 排序字段加入索引。
索引应尽量使用字节数小的列，对于重复值多的列不建议使用索引。
连接节点优化建议
每次使用执行计划前，先对表进行分析（analyze [表名]）。
调整合适的连接顺序（选择率低的join先执行）
耗时节点的合理性
1、数据扫描是否可以走索引、分区、物化视图？
返回大量行数的表，采用顺序扫描。
返回行数较少的表，采用索引扫描。
2、多表的连接顺序是否合理？
当使用3张表查询时（1张表数据小，2张表数据大），在做连接操作性，可以先让大表和小表连接，再去连接另一张大表。
3、两张表的连接算法是否合理？
查看基数估算结果是否准确，出现2表连接方式不合理。
4、返回行数估算是否准确？
比较估算成本与实际成本。若统计信息差距过大，进而导致选择了次优的执行计划。
5、是否有内存不足的情况？
当存在排序等情况时，操作的表超过了work_mem时，可以考虑适当增加该参数大小。
MySQL执行计划怎么看
注：
1、id相同：执行顺序由上至下
2、id不同：如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
3、id相同又不同（两种情况同时存在）：id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行
使用explain关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的，分析你的查询语句或是表结构的性能瓶颈。
explain执行计划包含的信息
其中最重要的字段为：id、type、key、rows、Extra
各字段详解
id
select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序
三种情况：
1、id相同：执行顺序由上至下
2、id不同：如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
3、id相同又不同（两种情况同时存在）：id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行
select_type
查询的类型，主要是用于区分普通查询、联合查询、子查询等复杂的查询
1、SIMPLE：简单的select查询，查询中不包含子查询或者union
2、PRIMARY：查询中包含任何复杂的子部分，最外层查询则被标记为primary
3、SUBQUERY：在select 或 where列表中包含了子查询
4、DERIVED：在from列表中包含的子查询被标记为derived（衍生），mysql或递归执行这些子查询，把结果放在零时表里
5、UNION：若第二个select出现在union之后，则被标记为union；若union包含在from子句的子查询中，外层select将被标记为derived
6、UNION RESULT：从union表获取结果的select
type
访问类型，sql查询优化中一个很重要的指标，结果值从好到坏依次是：
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
一般来说，好的sql查询至少达到range级别，最好能达到ref
1、system：表只有一行记录（等于系统表），这是const类型的特例，平时不会出现，可以忽略不计
2、const：表示通过索引一次就找到了，const用于比较primary key 或者 unique索引。因为只需匹配一行数据，所有很快。如果将主键置于where列表中，mysql就能将该查询转换为一个const
3、eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键 或 唯一索引扫描。
注意：ALL全表扫描的表记录最少的表如t1表
4、ref：非唯一性索引扫描，返回匹配某个单独值的所有行。本质是也是一种索引访问，它返回所有匹配某个单独值的行，然而他可能会找到多个符合条件的行，所以它应该属于查找和扫描的混合体
5、range：只检索给定范围的行，使用一个索引来选择行。key列显示使用了那个索引。一般就是在where语句中出现了bettween、<、>、in等的查询。这种索引列上的范围扫描比全索引扫描要好。只需要开始于某个点，结束于另一个点，不用扫描全部索引
6、index：Full Index Scan，index与ALL区别为index类型只遍历索引树。这通常为ALL块，应为索引文件通常比数据文件小。（Index与ALL虽然都是读全表，但index是从索引中读取，而ALL是从硬盘读取）
7、ALL：Full Table Scan，遍历全表以找到匹配的行
possible_keys
查询涉及到的字段上存在索引，则该索引将被列出，但不一定被查询实际使用
key
实际使用的索引，如果为NULL，则没有使用索引。
查询中如果使用了覆盖索引，则该索引仅出现在key列表中
key_len
表示索引中使用的字节数，查询中使用的索引的长度（最大可能长度），并非实际使用长度，理论上长度越短越好。key_len是根据表定义计算而得的，不是通过表内检索出的
ref
显示索引的那一列被使用了，如果可能，是一个常量const。
rows
根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数
Extra
不适合在其他字段中显示，但是十分重要的额外信息
1、Using filesort ：
mysql对数据使用一个外部的索引排序，而不是按照表内的索引进行排序读取。也就是说mysql无法利用索引完成的排序操作成为“文件排序”
由于索引是先按email排序、再按address排序，所以查询时如果直接按address排序，索引就不能满足要求了，mysql内部必须再实现一次“文件排序”
2、Using temporary：
使用临时表保存中间结果，也就是说mysql在对查询结果排序时使用了临时表，常见于order by 和 group by
3、Using index：
表示相应的select操作中使用了覆盖索引（Covering Index），避免了访问表的数据行，效率高
如果同时出现Using where，表明索引被用来执行索引键值的查找（参考上图）
如果没用同时出现Using where，表明索引用来读取数据而非执行查找动作
覆盖索引（Covering Index）：也叫索引覆盖。就是select列表中的字段，只用从索引中就能获取，不必根据索引再次读取数据文件，换句话说查询列要被所建的索引覆盖。
注意：
a、如需使用覆盖索引，select列表中的字段只取出需要的列，不要使用select *
b、如果将所有字段都建索引会导致索引文件过大，反而降低crud性能
4、Using where ：
使用了where过滤
5、Using join buffer ：
使用了链接缓存
6、Impossible WHERE：
where子句的值总是false，不能用来获取任何元祖
7、select tables optimized away：
在没有group by子句的情况下，基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT（*）操作，不必等到执行阶段在进行计算，查询执行计划生成的阶段即可完成优化
8、distinct：
优化distinct操作，在找到第一个匹配的元祖后即停止找同样值得动作
综合Case
执行顺序
1（id = 4）、【select id, name from t2】：select_type 为union，说明id=4的select是union里面的第二个select。
2（id = 3）、【select id, name from t1 where address = ‘11’】：因为是在from语句中包含的子查询所以被标记为DERIVED（衍生），where address = ‘11’ 通过复合索引idx_name_email_address就能检索到，所以type为index。
3（id = 2）、【select id from t3】：因为是在select中包含的子查询所以被标记为SUBQUERY。
4（id = 1）、【select d1.name, … d2 from … d1】：select_type为PRIMARY表示该查询为最外层查询，table列被标记为 “derived3”表示查询结果来自于一个衍生表（id = 3 的select结果）。
5（id = NULL）、【 … union … 】：代表从union的临时表中读取行的阶段，table列的 “union 1, 4”表示用id=1 和 id=4 的select结果进行union操作。
文章知识点与官方知识档案匹配，可进一步学习相关知识
SQL Server的执行计划怎么看？
17 篇文章1 订阅
订阅专栏
执行计划
一、背景
二、显示和保存执行计划
三、显示估计的执行计划
四、显示实际执行计划
五、以 XML 格式保存执行计划
六、比较和分析执行计划
6.1、比较执行计划
6.2、分析实际执行计划
总结
一、背景
为了能够执行查询，SQL Server 数据库引擎必须分析该语句，以确定访问所需数据的最有效方法。此分析由称为查询优化器的组件处理。查询优化器的输入由查询、数据库架构（表和索引定义）和数据库统计信息组成。查询优化器的输出是查询执行计划，有时称为查询计划或执行计划。
查询执行计划是以下内容的定义：
访问源表的顺序。通常，数据库服务器可以在许多序列中访问基表以生成结果集。
用于从每个表中提取数据的方法。通常，访问每个表中的数据有不同的方法。如果只需要具有特定键值的几行，则数据库服务器可以使用索引。如果表中的所有行都是必需的，数据库服务器可以忽略索引并执行表扫描。如果表中的所有行都是必需的，但有一个索引的键列位于 中，则执行索引扫描而不是表扫描可能会保存单独的结果集。如果表非常小，则表扫描可能是几乎所有访问表的最有效方法。
用于计算计算的方法，以及如何筛选、聚合和排序每个表中的数据。从表中访问数据时，有不同的方法可以对数据执行计算（例如计算标量值），以及聚合和排序查询文本中定义的数据，以及如何筛选数据。
二、显示和保存执行计划
执行计划以图形方式显示 SQL Server 查询优化器选择的数据检索方法。执行计划使用图标而不是 SET SHOWPLAN_ALL或 SET SHOWPLAN_TEXT 语句生成的表格表示形式来表示 SQL Server 中特定语句和查询的执行开销。这种图形方法对于了解查询的性能特征非常有用。
虽然 SQL Server 查询优化器只生成一个执行计划，但存在估计执行计划和实际执行计划的概念。
估计的执行计划返回查询优化器在编译时生成的执行计划。生成估计的执行计划不会实际执行查询或批处理，因此不包含任何运行时信息，例如实际资源使用情况指标或运行时警告。
实际执行计划返回查询优化器生成的执行计划，并在查询或批处理完成后返回执行计划。这包括有关资源使用情况指标和任何运行时警告的运行时信息。
三、显示估计的执行计划
生成估计的执行计划时，不会执行 T-SQL 查询或批处理。因此，估计的执行计划不包含任何运行时信息，例如实际资源使用情况指标或运行时警告。相反，生成的执行计划显示 SQL Server 数据库引擎在实际执行查询时最有可能使用的查询执行计划，并显示流经计划中多个运算符的估计行。
若要使用此功能，用户必须具有执行要为其生成图形执行计划的 T-SQL 查询的适当权限，并且必须向他们授予查询引用的所有数据库的 SHOWPLAN 权限。
通过 SSMS、EXPLAIN 和 SET SHOWPLAN_XML的估计执行计划可用于 Azure Synapse Analytics 中的专用 SQL 池（以前称为 SQL DW）和专用 SQL 池。
注意：使用 SET SHOWPLAN_XML返回每个语句的执行计划信息而不执行它。
四、显示实际执行计划
实际执行计划是在执行 T-SQL 查询或批处理后生成的。因此，实际执行计划包含运行时信息，例如实际资源使用指标和运行时警告（如果有）。生成的执行计划显示 SQL Server 数据库引擎用于执行查询的实际查询执行计划。
若要使用此功能，用户必须具有执行正在为其生成图形执行计划的 Transact-SQL 查询的适当权限，并且必须向他们授予查询引用的所有数据库的 SHOWPLAN 权限。
五、以 XML 格式保存执行计划
要执行计划功能或使用 XML 显示计划 SET 选项，用户必须具有执行要为其生成执行计划的 Transact-SQL 查询的适当权限，并且必须向他们授予查询引用的所有数据库的 SHOWPLAN 权限。
使用以下语句打开SHOWPLAN_XML：
SET SHOWPLAN_XML ON;
GO
1
2
若要打开统计信息 XML，请使用以下语句：
SET STATISTICS XML ON;
GO
执行查询：
USE AdventureWorks2012;
GO
SET SHOWPLAN_XML ON;
GO
– Execute a query.
SELECT BusinessEntityID
FROM HumanResources.Employee
WHERE NationalIDNumber = ‘509647174’;
GO
SET SHOWPLAN_XML OFF;
六、比较和分析执行计划
执行计划以图形方式显示 SQL Server 查询优化器选择的数据检索方法。执行计划使用图标而不是 SET SHOWPLAN_ALL或 SET SHOWPLAN_TEXT 语句生成的表格表示形式来表示 SQL Server 中特定语句和查询的执行开销。这种图形方法对于理解查询的性能特征非常有用。
SQL Server Management Studio 包含的功能允许用户比较两个执行计划（例如，同一查询的感知好计划和坏计划），并执行根本原因分析。还包括执行单个查询计划分析的功能，允许通过分析查询的执行计划来深入了解可能影响查询性能的方案。
6.1、比较执行计划
出于故障排除原因，数据库专业人员可能必须执行比较计划的功能：
查找查询或批处理突然变慢的原因。
了解查询重写的影响。
观察引入架构设计的特定性能增强更改（如新索引）如何有效地更改执行计划。
可以在以下两者之间进行比较：
两个以前保存的执行计划文件（扩展名为 .sqlplan）。
一个活动的执行计划和一个以前保存的查询执行计划。
查询存储中的两个选定查询计划。
比较两个执行计划时，计划中执行基本相同的区域将以相同的颜色和图案突出显示。单击一个计划中的颜色区域会将另一个计划居中放在该计划中的匹配节点上。仍然可以比较执行计划的不匹配运算符和节点，但在这种情况下，必须手动选择要比较的运算符。
6.2、分析实际执行计划
查询性能故障排除需要在了解查询处理和执行计划方面具有丰富的专业知识，以便能够实际查找和修复根本原因。
SQL Server Management Studio 包括在实际执行计划分析任务中实现某种程度自动化的功能，尤其是对于大型和复杂的计划。目标是更轻松地查找基数估计不准确的方案，并获取有关可能可用的缓解措施的建议。
总结
实际执行计划是在事务处理 SQL 查询或批处理执行后生成的。因此，实际执行计划包含运行时信息，例如实际行数、资源使用指标和运行时警告（如果有）。
只有考虑更改计划形状的节点才会用于检查相似性。因此，在计划同一子部分中的两个节点的中间可能存在一个未着色的节点。在这种情况下，缺少颜色意味着在检查部分是否相等时未考虑节点。
在将建议的缓解措施应用于生产环境之前，请确保对其进行适当的测试。
文章知识点与官方知识档案匹配，可进一步学习相关知识
DB2 查看执行计划
使用命令行查看执行计划
1.如果第一次执行,请先 connect to dbname,
2.执行db2 -tvf $HOME/sqllib/misc/EXPLAIN.DDL建立执行计划表
3.db2 set current explain mode explain
设置成解释模式,并不真正执行下面将发出的sql命令
4.db2 "select order_number from <table_name>where order_number=‘000000000036’ and mer_ID=‘111’ and order_time=‘20121111111111’ and order_type=‘01’ "
执行你想要分析的sql语句
5.db2 set current explain mode no
取消解释模式
6.db2exfmt -d XXX -g TIC -w -l -s % -n % -o db2exmt.out
执行计划输出到文件db2exmt.out
详细步骤：
db2inst1@mkt1:/dmt01_inst/db2inst1/enmotech/steven > db2 set current explain mode explain
DB20000I The SQL command completed successfully.
db2inst1@mkt1:/dmt01_inst/db2inst1/enmotech/steven > db2 “SELECT ‘grant all on table ’ ||tabschema||’.’||tabname|| ’ to user GZ851;’ FROM syscat.tables WHERE owner in (‘LIUNIAN1’,‘SUNJING1’,‘CHENJ1’,‘FUWEI1’,‘WANGP1’,‘ZHOUY1’) and CREATE_TIME>(current TIMESTAMP - 1 days)”
SQL0217W The statement was not executed as only Explain information requests
are being processed. SQLSTATE=01604
db2inst1@mkt1:/dmt01_inst/db2inst1/enmotech/steven > db2 set current explain mode no
DB20000I The SQL command completed successfully.
db2inst1@mkt1:/dmt01_inst/db2inst1/enmotech/steven > db2exfmt -d gzdmt -g TIC -w -l -s % -n % -o db2exmt.out
DB2 Universal Database Version 9.5, 5622-044 © Copyright IBM Corp. 1991, 2007
Licensed Material - Program Property of IBM
IBM DATABASE 2 Explain Table Format Tool
Connecting to the Database.
Connect to Database Successful.
Enter up to 26 character Explain timestamp (Default -1) ==>
Enter section number (0 for all, Default 0) ==>
Output is in db2exmt.out.
Executing Connect Reset – Connect Reset was Successful.
db2inst1@mkt1:/dmt01_inst/db2inst1/enmotech/steven >
db2inst1@mkt1:/dmt01_inst/db2inst1/enmotech/steven > cat db2exmt.out
DB2 Universal Database Version 9.5, 5622-044 © Copyright IBM Corp. 1991, 2007
Licensed Material - Program Property of IBM
IBM DATABASE 2 Explain Table Format Tool
******************** EXPLAIN INSTANCE ********************
DB2_VERSION: 09.05.4
SOURCE_NAME: SQLC2G15
SOURCE_SCHEMA: NULLID
SOURCE_VERSION:
EXPLAIN_TIME: 2014-09-23-13.50.10.797690
EXPLAIN_REQUESTER: DB2INST1
Database Context:
Parallelism: Inter-Partition Parallelism
CPU Speed: 3.542582e-07
Comm Speed: 100
Buffer Pool size: 303110
Sort Heap size: 50000
Database Heap size: 2610
Lock List size: 3200
Maximum Lock List: 60
Average Applications: 1
Locks Available: 122880
Package Context:
SQL Type: Dynamic
Optimization Level: 7
Blocking: Block All Cursors
Isolation Level: Cursor Stability
---------------- STATEMENT 1 SECTION 201 ----------------
QUERYNO: 3
QUERYTAG: CLP
Statement Type: Select
Updatable: No
Deletable: No
Query Degree: 1
Original Statement:
SELECT ‘grant all on table ’ ||tabschema||’.’||tabname|| ’ to user GZ851;’
FROM syscat.tables
WHERE owner in (‘LIUNIAN1’,‘SUNJING1’,‘CHENJ1’,‘FUWEI1’,‘WANGP1’,‘ZHOUY1’)
and CREATE_TIME>(current TIMESTAMP - 1 days)
Optimized Statement:
SELECT (‘grant all on table ’ || Q3.“CREATOR” || ‘.’ || Q3.“NAME” || ’ to
user GZ851;’)
FROM SYSIBM.SYSTABLES AS Q3
WHERE ($C0 < Q3.“CTIME”) AND Q3.“DEFINER” IN (‘LIUNIAN1’, ‘SUNJING1’,
‘CHENJ1’, ‘FUWEI1’, ‘WANGP1’, ‘ZHOUY1’)
Access Plan:
Total Cost: 87045.4
Query Degree: 1
Rows
RETURN
( 1)
Cost
I/O
|
0.697114
DTQ
( 2)
87045.4
44496
|
0.697114
TBSCAN
( 3)
87045.4
44496
|
314720
TABLE: SYSIBM
SYSTABLES
Q3
Extended Diagnostic Information:
Diagnostic formatting function does no exist. No extended Diagnostic Information is available.
Plan Details:
1) RETURN: (Return Result)
Cumulative Total Cost: 87045.4
Cumulative CPU Cost: 8.91113e+08
Cumulative I/O Cost: 44496
Cumulative Re-Total Cost: 241.791
Cumulative Re-CPU Cost: 6.82527e+08
Cumulative Re-I/O Cost: 0
Cumulative First Row Cost: 87045.2
Cumulative Comm Cost: 1.14643
Cumulative First Comm Cost: 0
Estimated Bufferpool Buffers: 44496
Arguments:
---------
BLDLEVEL: (Build level)
DB2 v9.5.0.4 : s090429
HEAPUSE : (Maximum Statement Heap Usage)
192 Pages
PREPNODE: (Prepare Node Number)
0
PREPTIME: (Statement prepare time)
17 milliseconds
STMTHEAP: (Statement heap size)
4096
Input Streams:
-------------
3) From Operator #2
Estimated number of rows: 0.697114
Partition Map ID: -100
Partitioning: (COOR )
Coordinator Partition
Number of columns: 1
Subquery predicate ID: Not Applicable
Column Names:
------------
+Q4.$C0
Partition Column Names:
----------------------
+NONE
2) TQ : (Table Queue)
Cumulative Total Cost: 87045.4
Cumulative CPU Cost: 8.91113e+08
Cumulative I/O Cost: 44496
Cumulative Re-Total Cost: 241.791
Cumulative Re-CPU Cost: 6.82527e+08
Cumulative Re-I/O Cost: 0
Cumulative First Row Cost: 87045.2
Cumulative Comm Cost: 1.14643
Cumulative First Comm Cost: 0
Estimated Bufferpool Buffers: 44496
Arguments:
---------
LISTENER: (Listener Table Queue type)
FALSE
TQMERGE : (Merging Table Queue flag)
FALSE
TQREAD : (Table Queue Read type)
READ AHEAD
TQSEND : (Table Queue Write type)
DIRECTED
UNIQUE : (Uniqueness required flag)
FALSE
Input Streams:
-------------
2) From Operator #3
Estimated number of rows: 0.697114
Partition Map ID: 0
Partitioning: ( 0)
Single Node (# 0) Partition
Number of columns: 1
Subquery predicate ID: Not Applicable
Column Names:
------------
+Q4.$C0
Partition Column Names:
----------------------
+NONE
Output Streams:
--------------
3) To Operator #1
Estimated number of rows: 0.697114
Partition Map ID: -100
Partitioning: (COOR )
Coordinator Partition
Number of columns: 1
Subquery predicate ID: Not Applicable
Column Names:
------------
+Q4.$C0
Partition Column Names:
----------------------
+NONE
3) TBSCAN: (Table Scan)
Cumulative Total Cost: 87045.4
Cumulative CPU Cost: 8.91016e+08
Cumulative I/O Cost: 44496
Cumulative Re-Total Cost: 241.791
Cumulative Re-CPU Cost: 6.82527e+08
Cumulative Re-I/O Cost: 0
Cumulative First Row Cost: 87045.1
Cumulative Comm Cost: 0
Cumulative First Comm Cost: 0
Estimated Bufferpool Buffers: 44496
Arguments:
---------
MAXPAGES: (Maximum pages for prefetch)
ALL
PREFETCH: (Type of Prefetch)
SEQUENTIAL
ROWLOCK : (Row Lock intent)
NEXT KEY SHARE
SCANDIR : (Scan Direction)
FORWARD
TABLOCK : (Table Lock intent)
INTENT SHARE
TBISOLVL: (Table access Isolation Level)
CURSOR STABILITY
Predicates:
----------
4) Sargable Predicate
Comparison Operator: Less Than (<)
Subquery Input Required: No
Filter Factor: 0.0031687
Predicate Text:
--------------
($C0 < Q3."CTIME")
5) Sargable Predicate
Comparison Operator: In List (IN), evaluated by binary search (list sorted at compile-time)
Subquery Input Required: No
Filter Factor: 0.000699034
Predicate Text:
--------------
Q3."DEFINER" IN ('LIUNIAN1', 'SUNJING1', 'CHENJ1',
'FUWEI1', 'WANGP1', 'ZHOUY1')
Input Streams:
-------------
1) From Object SYSIBM.SYSTABLES
Estimated number of rows: 314720
Partition Map ID: 0
Partitioning: ( 0)
Single Node (# 0) Partition
Number of columns: 5
Subquery predicate ID: Not Applicable
Column Names:
------------
+Q3.$RID$+Q3."CTIME"+Q3."DEFINER"+Q3."NAME"
+Q3."CREATOR"
Partition Column Names:
----------------------
+NONE
Output Streams:
--------------
2) To Operator #2
Estimated number of rows: 0.697114
Partition Map ID: 0
Partitioning: ( 0)
Single Node (# 0) Partition
Number of columns: 1
Subquery predicate ID: Not Applicable
Column Names:
------------
+Q4.$C0
Partition Column Names:
----------------------
+NONE
Objects Used in Access Plan:
Schema: SYSIBM
Name: SYSAUDITPOLICIES
Type: Table (reference only)
Schema: SYSIBM
Name: SYSCOLLATIONS
Type: Table (reference only)
Schema: SYSCAT
Name: TABLES
Type: View (reference only)
Schema: SYSIBM
Name: SYSTABLES
Type: Table
Time of creation: 2009-06-30-09.32.06.716136
Last statistics update: 2014-08-30-09.15.44.749749
Number of columns: 71
Number of rows: 314720
Width of rows: 3383
Number of buffer pool pages: 44384
Number of data partitions: 1
Distinct row values: No
Tablespace name: SYSCATSPACE
Tablespace overhead: 7.500000
Tablespace transfer rate: 0.060000
Source for statistics: Single Node
Prefetch page count: 24
Container extent page count: 4
Table overflow record count: 112
Table Active Blocks: -1
Average Row Compression Ratio: 0
Percentage Rows Compressed: 0
Average Compressed Row Size: 0
db2inst1@mkt1:/dmt01_inst/db2inst1/enmotech/steven >
