达梦数据库执行计划查看

概述

在数据库查询中，难免有SQL语句执行时间不满足预期，这个时候需要查看SQL执行计划，以便对SQL进行优化。下面将介绍达梦数据库如何查看执行计划及涉及相关工具。

1.执行计划查看顺序和说明

1.1 执行计划查看顺序

执行计划就是一条 SQL 语句在数据库中的执行过程或访问路径的描述。在遇到数据库性能问题时，往往需要查看慢SQL执行计划，下面就是一个例子：

缩进越多的越先执行，同样缩进的上面的先执行，

下面的后执行，上下的优先级高于内外。

缩进最深的，最先执行；

缩进深度相同的，先上后下。

口诀：最右最上先执行。

1.2 执行计划查看说明

以上面1.1执行计划输出内容为例，执行计划的每行即为一个计划节点，主要包含三部分信息。

• 第1部分 NEST2、PRJT2、CSCN2 为操作符及数据库具体执行了什么操作。
• 第2部分 三元组为该计划节点的执行代价，具体含义为[代价，记录行数，字节数]。
• 第3部分 为操作符的补充信息。

#CSCN2: [1, 856, 285]; INDEX33555892(EMPLOYEE)
 操作符，[代价，行数，字节数] 描述

以上面一行输出信息为例进行说明，操作符进行CSCN2了全表扫描，估算代价是1，行数是856行，涉及285个字节。

2.通过什么工具查看执行计划

2.1 通过 DM 数据库管理工具查看

如下图所示，选择查询语句后，点击按钮【显示执行计划P】或者执行【F9】即可查看SQL语句执行计划。

2.2 通过 explain 命令查看

通过disql 登录到数据库中，使用explain命令查看执行计划，如下图所示：

3. 操作符说明

达梦中执行计划涉及到的一些主要操作符有如下表格，因执行计划操作都是英文缩写，为更好的理解操作符操作缩写含义，专门对其缩写前的英文描述进行整理。

接下来结合实例来介绍下这些操作符：

准备测试数据：

DROP TABLE T1;
DROP TABLE T2;
CREATE TABLE T1(C1 INT ,C2 CHAR(1),C3 VARCHAR(10) ,C4 VARCHAR(10) );
CREATE TABLE T2(C1 INT ,C2 CHAR(1),C3 VARCHAR(10) ,C4 VARCHAR(10) );
INSERT INTO T1
SELECT LEVEL C1,CHR(65+MOD(LEVEL,57)) C2,'TEST',NULL FROM DUAL
CONNECT BY LEVEL<=10000;
INSERT INTO T2
SELECT LEVEL C1,CHR(65+MOD(LEVEL,57)) C2,'TEST',NULL  FROM DUAL
CONNECT BY LEVEL<=10000;
CREATE INDEX IDX_C1_T1 ON T1(C1);
SP_INDEX_STAT_INIT(USER,'IDX_C1_T1');

3.1 NSET收集结果集

SQL> EXPLAIN SELECT * FROM T1;
 
1   #NSET2: [1, 10000, 156] 
2     #PRJT2: [1, 10000, 156]; exp_num(5), is_atom(FALSE) 
3       #CSCN2: [1, 10000, 156]; INDEX33555483(T1)
 
已用时间: 0.458(毫秒). 执行号:0.

NSET 是用于结果集收集的操作符，一般是查询计划的顶层节点，优化中无需对该操作符过多关注。

3.2 PRJT投影

SQL> EXPLAIN SELECT * FROM T1;
 
1   #NSET2: [1, 10000, 156] 
2     #PRJT2: [1, 10000, 156]; exp_num(5), is_atom(FALSE) 
3       #CSCN2: [1, 10000, 156]; INDEX33555483(T1)
 
已用时间: 0.544(毫秒). 执行号:0.

投影(project)运算，就是选择查询的列，用于选择表达式项的计算;广泛用于查询，排序，函数索引创建等。

3.3 SLCT选择

SQL>  EXPLAIN SELECT * FROM T1 WHERE C2='TEST';
 
1   #NSET2: [1, 250, 156] 
2     #PRJT2: [1, 250, 156]; exp_num(5), is_atom(FALSE) 
3       #SLCT2: [1, 250, 156]; T1.C2 = 'TEST'
4         #CSCN2: [1, 10000, 156]; INDEX33555483(T1)
 
已用时间: 0.634(毫秒). 执行号:0.

SLCT操作符，用于查询条件的过滤，如果代价比较高，要考虑是否在查询条件相关列添加索引，及是分析是否有合适的索引。

3.4 CSCN全表扫描

SQL> EXPLAIN SELECT * FROM T1;
 
1   #NSET2: [1, 10000, 156] 
2     #PRJT2: [1, 10000, 156]; exp_num(5), is_atom(FALSE) 
3       #CSCN2: [1, 10000, 156]; INDEX33555483(T1)
 
已用时间: 0.465(毫秒). 执行号:0.
SQL> 

CSCN操作符是 CLUSTER INDEX SCAN 的缩写，通过聚集索引扫描全表，全表扫描 I/O 开销较大，如果没有选择谓词，或者没有索引可以利用，则一般只能做全表扫描。表数据量大的情况，应该避免通过添加有索引的查询条件。

3.5 BLKUP二次扫描

SQL> EXPLAIN SELECT * FROM T1 WHERE C1=10;
 
1   #NSET2: [1, 1, 156] 
2     #PRJT2: [1, 1, 156]; exp_num(5), is_atom(FALSE) 
3       #BLKUP2: [1, 1, 156]; IDX_C1_T1(T1)
4         #SSEK2: [1, 1, 156]; scan_type(ASC), IDX_C1_T1(T1), scan_range[10,10]
 
已用时间: 0.757(毫秒). 执行号:0.

3.6 SSEK二级索引扫

SQL> EXPLAIN SELECT * FROM T1 WHERE C1=10;
 
1   #NSET2: [1, 1, 156] 
2     #PRJT2: [1, 1, 156]; exp_num(5), is_atom(FALSE) 
3       #BLKUP2: [1, 1, 156]; IDX_C1_T1(T1)
4         #SSEK2: [1, 1, 156]; scan_type(ASC), IDX_C1_T1(T1), scan_range[10,10]
 
已用时间: 0.768(毫秒). 执行号:0.

SSEK2是二级索引扫描即先扫描索引，再通过主键、聚集索引、rowid 等信息去扫描表。

3.7 SSCN索引全扫描

SQL> CREATE INDEX IDX_C1_C2_T1 ON T1(C1,C2);
操作已执行
已用时间: 21.082(毫秒). 执行号:9101.
SQL> EXPLAIN SELECT C1,C2 FROM T1;
 
1   #NSET2: [1, 10000, 60] 
2     #PRJT2: [1, 10000, 60]; exp_num(3), is_atom(FALSE) 
3       #SSCN: [1, 10000, 60]; IDX_C1_C2_T1(T1)
 
已用时间: 0.656(毫秒). 执行号:0.

SSCN 是索引全扫描，不需要扫描表。

3.8 CSEK聚集索引扫描

SQL> CREATE CLUSTER INDEX IDX_C1_T2 ON T2(C1);
操作已执行
已用时间: 105.336(毫秒). 执行号:9102.
SQL> EXPLAIN SELECT * FROM T2 WHERE C1=10;
 
1   #NSET2: [1, 250, 156] 
2     #PRJT2: [1, 250, 156]; exp_num(5), is_atom(FALSE) 
3       #CSEK2: [1, 250, 156]; scan_type(ASC), IDX_C1_T2(T2), scan_range[10,10]
 
已用时间: 0.728(毫秒). 执行号:0.
SQL>

3.9 NEST LOOP嵌套循环连接

SQL>  explain select /*+use_nl(t1,t2)*/* from t1 inner join t2 on t1.c1=t2.c1 where t1.c2='A';
 
1   #NSET2: [17862, 24950, 296] 
2     #PRJT2: [17862, 24950, 296]; exp_num(8), is_atom(FALSE) 
3       #SLCT2: [17862, 24950, 296]; T1.C1 = T2.C1
4         #NEST LOOP INNER JOIN2: [17862, 24950, 296]; 
5           #SLCT2: [1, 250, 148]; T1.C2 = 'A'
6             #CSCN2: [1, 10000, 148]; INDEX33555483(T1)
7           #CSCN2: [1, 10000, 148]; IDX_C1_T2(T2)
 
已用时间: 0.787(毫秒). 执行号:0.
SQL>

原理:

两层嵌套循环结构，有驱动表和被驱动表之分。 选定一张表作为驱动表，遍历驱动表中的每一行，根据连接条件去匹配第二 张表中的行。驱动表的行数就是循环的次数，这个很大程度影响了执行效率。

需注意的问题:

选择小表作为驱动表。统计信息尽量准确，保证优化器选对驱动表。

大量的随机读。如果没有索引，随机读很致命，每次循环只能读一块， 不能读多块。使用索引可以解决这个问题。

连接列是否有索引，都可以走 NEST LOOP，但没有索引，执行效率会很差，可针对 T1 和 T2 的连接列创建索引，并收集统计信息，语句如下所示：

CREATE INDEX IDX_T1_C2  ON T1(C2);
CREATE INDEX IDX_T2_C1  ON T2(C1);
DBMS_STATS.GATHER_INDEX_STATS(USER,'IDX_T1_C2');
DBMS_STATS.GATHER_INDEX_STATS(USER,'IDX_T2_C1');

再次查看执行计划，执行成本明显下降：

SQL> explain select /*+use_nl(t1,t2)*/* from t1 inner join t2 on t1.c1=t2.c1 where t1.c2='A';
 
1   #NSET2: [9805, 17465, 296] 
2     #PRJT2: [9805, 17465, 296]; exp_num(8), is_atom(FALSE) 
3       #SLCT2: [9805, 17465, 296]; T1.C1 = T2.C1
4         #NEST LOOP INNER JOIN2: [9805, 17465, 296]; 
5           #BLKUP2: [1, 175, 148]; IDX_T1_C2(T1)
6             #SSEK2: [1, 175, 148]; scan_type(ASC), IDX_T1_C2(T1), scan_range['A','A']
7           #CSCN2: [1, 10000, 148]; IDX_C1_T2(T2)
 
已用时间: 0.796(毫秒). 执行号:0.

适用场景：

• 驱动表有很好的过滤条件
• 表连接条件能使用索引
• 结果集比较小

3.10 AAGR简单聚集

SQL> EXPLAIN SELECT COUNT(*) FROM T1 WHERE C1 = 10;
 
1   #NSET2: [1, 1, 4] 
2     #PRJT2: [1, 1, 4]; exp_num(1), is_atom(FALSE) 
3       #AAGR2: [1, 1, 4]; grp_num(0), sfun_num(1), distinct_flag[0]; slave_empty(0)
4         #SSEK2: [1, 1, 4]; scan_type(ASC), IDX_C1_T1(T1), scan_range[10,10]
 
已用时间: 0.712(毫秒). 执行号:0.
SQL> 

AAGR用于没有GROUP BY的COUNT、SUM、AGE、MAX、MIN等聚集函数的计算。

3.11FAGR快速聚集

SQL> EXPLAIN  SELECT MAX(C1) FROM T1;
 
1   #NSET2: [1, 1, 4] 
2     #PRJT2: [1, 1, 4]; exp_num(1), is_atom(FALSE) 
3       #FAGR2: [1, 1, 4]; sfun_num(1), IDX_C1_T1
 
已用时间: 0.541(毫秒). 执行号:0.
SQL> 

3.12HASH分组聚集

SQL> EXPLAIN SELECT COUNT(*) FROM T1 GROUP BY C2;
 
1   #NSET2: [2, 100, 48] 
2     #PRJT2: [2, 100, 48]; exp_num(1), is_atom(FALSE) 
3       #HAGR2: [2, 100, 48]; grp_num(1), sfun_num(1), distinct_flag[0]; slave_empty(0) keys(T1.C2) 
4         #CSCN2: [1, 10000, 48]; INDEX33555492(T1)
 
已用时间: 0.480(毫秒). 执行号:0.
SQL>

HAGR 用于分组列没有索引只能走全表扫描的分组聚集，该示例中 C2 列没有创建索引。

3.13 SAGR流分组聚集

SQL> EXPLAIN SELECT COUNT(*) FROM T1 GROUP BY C1;
 
1   #NSET2: [2, 100, 4] 
2     #PRJT2: [2, 100, 4]; exp_num(1), is_atom(FALSE) 
3       #SAGR2: [2, 100, 4]; grp_num(1), sfun_num(1), distinct_flag[0]; slave_empty(0) keys(T1.C1) 
4         #SSCN: [1, 10000, 4]; IDX_C1_T1(T1)
 
已用时间: 0.547(毫秒). 执行号:0.

SAGR 用于分组列是有序的情况下，可以使用流分组聚集，C1 列上已经创建了索引，SAGR2 性能优于 HAGR2。

3.14 HASH JOIN哈希连接

SQL> EXPLAIN select * from t1 inner join t2 on t1.c1=t2.c1 where t1.c2='A';
 
1   #NSET2: [4, 24502, 296] 
2     #PRJT2: [4, 24502, 296]; exp_num(8), is_atom(FALSE) 
3       #HASH2 INNER JOIN: [4, 24502, 296];  KEY_NUM(1); KEY(T1.C1=T2.C1) KEY_NULL_EQU(0)
4         #SLCT2: [1, 250, 148]; T1.C2 = 'A'
5           #CSCN2: [1, 10000, 148]; INDEX33555492(T1)
6         #CSCN2: [1, 10000, 148]; INDEX33555493(T2)
 
已用时间: 0.829(毫秒). 执行号:0.
SQL>

使用较小的Row source 作为Hash table和Bitmap， 而第二个row source被hashed，根据bitmap与第一个row source生成的hash table 相匹配，bitmap查找的速度极快。

hash join特点：

一般没索引或用不上索引时会使用该连接方式。

选择小的表(或row source)做hash表。

只适用等值连接中的情形。

由于hash连接比较消耗内存，如果有很多这种连接时，需调整以下3个参数:

HJ_BUF_GLOBAL_SIZE

HJ_BUF_SIZE

HJ_BLK_SIZE

3.15 MERGE JOIN归并排序连接

EXPLAIN select /*+use_merge(t1 t2)*/t1.c1,t2.c1 from t1 inner join t2 on t1.c1=t2.c1 where t2.c2='b';
1   #NSET2: [13, 24725, 56] 
2     #PRJT2: [13, 24725, 56]; exp_num(2), is_atom(FALSE) 
3       #SLCT2: [13, 24725, 56]; T2.C2 = 'b'
4         #MERGE INNER JOIN3: [13, 24725, 56]; KEY_NUM(1); KEY(COL_0 = COL_0) KEY_NULL_EQU(0)
5           #SSCN: [1, 10000, 4]; IDX_C1_T1(T1)
6           #BLKUP2: [1, 10000, 52]; IDX_T2_C1(T2)
7             #SSCN: [1, 10000, 52]; IDX_T2_C1(T2)

归并排序连接需要两张表的连接列都有索引，对两张表扫描索引后按照索引顺序进行归并。

无驱动表之分，随机读很少。两个表都需要按照连接列排序，需要消耗大量的cpu和额外的内存。

应用场景：

通常情况下，merge sort join需要消耗大量的cpu和内存，效率都不会太高。

如果存在相关索引可以消除sort，那么CBO可能会考虑该连接方式。