干货攻略 | 浅谈达梦SQL调优——执行计划和ET

达梦E学 2021-07-02

1677

/ 这是我的第215篇文章

达梦干货攻略

【Date：2021.07.01】

MY ARTICLE

在数据库的使用过程中，会用到大量的查询语句。为了节省时间和提高效率，对一些SQL进行调优是十分必要的。

在达梦数据库中，可以查看需要调整的SQL的执行计划并结合ET进行分析，来帮助寻找代价多的计划节点和操作符，指导我们进行SQL的优化。

本章内容已在如下环境上测试：

操作系统：CentOS7；

数据库：达梦数据库DM8。

GAN HUO

达梦的执行计划

1、什么是达梦的执行计划？

执行计划就是一条SQL语句在数据库中的执行过程或者访问路径的描述

2、如何查看执行计划

在需要查看执行计划的SQL语句前加上EXPLAIN关键字，再执行该条SQL，即可查看它的执行计划；

在达梦的管理工具中，可以选中需要查看的SQL语句，按下F9键也可以查看它的执行计划。

3、如何解读达梦的执行计划

explain select * from E9.DOCDETAILLOG where id=37；

执行计划看起来就像一棵树，执行过程为：控制流从上向下传递，数据流从下向上传递。

（1）每个字段解读一下：

名称：计划节点的操作符

附加信息：这个操作符具体执行了什么操作

代价：该操作符花费的时间

结果集：该操作符返回的结果条数

行数据处理长度：该执行节点的字节数

描述：对该操作符的简单描述

（2）解读该语句的执行计划的操作符：

NEST2:用于结果集收集的操作符

PRJT2:关系的投影运算，用于选择表达式的计算；

BLKUP2:二次扫描（回表）

SSEK2：二级索引扫描

（3）补充一些其他的常见操作符：

SLCT:选择，用于查询条件的过滤；

AAGR:简单聚集，用于没有GROUP BY的COUNT、SUM等聚集函数的计算；

HASH JOIN:哈希连接，在没有索引或索引无法使用情况下的表的连接方式。

（4）解读该SQL的执行计划：

通过ID列上的二级索引，过滤符合条件的数据行，接下来二次扫描表需要查询的其他数据行，对查询结果进行投影和收集；

说明：DM默认的表为索引组织表，每个表都有一个唯一的聚簇索引（clustered index ），除此之外的非聚簇索引都是二级索引（secondary indexes）。更多的操作符说明请参考《DM8管理员手册》。

GAN HUO

达梦ET

1、什么是ET

ET是达梦自带的系统存储过程，能统计SQL每个操作符的时间花费，从而定位到有性能问题的操作，指导我们去优化；

2、为什么使用ET

我们从上面的执行计划中知道了该SQL的执行过程，以及每个操作符和计划节点的代价，不过这个代价看上去还是有些抽象，ET可以把这些代价转化为具体的时间，帮助我们更好的有针对性的做出优化；

3、怎么使用ET

达梦ET默认未启用，设置启动以下三个参数可以启用ET（ENABLE_MONITOR、MONITOR_TIME和MONITOR_SQL_EXEC）；

其中，ENABLE_MONITOR和MONITOR_TIME默认已开启，如果未开启可以使用如下方法开启：

SP_SET_PARA_VALUE(1,'ENABLE_MONITOR',1);
SP_SET_PARA_VALUE(1,'MONITOR_TIME',1);

MONITOR_SQL_EXEC为会话级动态参数，可以设置只针对当前会话开启：

SF_SET_SESSION_PARA_VALUE('MONITOR_SQL_EXEC',1);

执行SQL语句，我们会看到一个执行号，直接点这个执行号，即可调用ET；

在知道执行号的情况下，CALL ET(124571);也可以这样使用ET；

这条SQL的ET：

ET结果说明：

OP: 操作符

TIME(us): 时间开销，单位为微秒

PERCENT: 执行时间占总时间百分比

RANK: 执行时间耗时排序

SEQ: 执行计划节点号

N_ENTER: 进入次数

GAN HUO

优化案例

1、案例一

select count(id)+1  from DocDetailLog where operatetype = 0 and docid =335;

（1）优化前的执行计划和ET

（2）优化过程：

从执行计划可以看出，执行过程首先进行了全表扫描，然后再进行条件的过滤，全表166003条数据，经条件过滤后，剩下54902条数据，过滤了的数据行还是比较多的，再根据该语句的ET来看，全表扫面花费了84.19%的时间，由此可以在选择条件上建立索引，避免全表扫描，提高执行效率；

select count(id)+1 from DocDetailLog where operatetype = 0 and docid =335;--81396
select count(*) from DocDetailLog where operatetype = 0;--111823
select count(*) from DocDetailLog where docid =335;--81396

分别对where后的条件进行选择，发现docid的过滤性更好，所以创建联合索引时docid放在前面；

create or REPLACE index idx_01 ON DocDetailLog(docid,operatetype);

创建索引后，收集统计信息：

重新查看执行计划：

创建索引后并没有使用，这是为什么呢，这里注意到operatertype这个字段，

它是字符型的，在SQL中没有加单引号，发生了隐式转换，这样是不走索引的；

select count(id)+1 from DocDetailLog where operatetype = '0' and docid =335;--81396

加上单引号后再看执行计划：

还是没有用到索引，这是因为优化器评估使用索引后，代价比不使用索引更大，所以优化器没有走索引；

我们这里可以强制使用该索引，查看执行计划，可以看到使用索引的话，在查询ID列时，需要进行表的二次扫描，这样的代价比不使用索引更大：

为了消除表的二次扫描，把ID列加入联合索引即可；

create or REPLACE index idx_01 ON DocDetailLog(docid,operatetype,id);

（3）优化后的执行计划和ET：

2、案例二

select * from "E9"."WORKFLOW_REQUESTBASE" where requestnamenew like '%zss%';

（1）优化前执行计划和ET：

看一下总的时间是7毫秒；

（2）优化过程：

查看执行计划，发现主要代价还是在全表扫描上，根据经验，在不优化的情况下首尾%肯定是不走索引，全表扫描的，这里的执行计划也验证了这一点。

在达梦数据库中，有一个参数like_opt_flag提供了针对查询条件中%的情况一些优化策略。

like_opt_flag：LIKE 查询的优化开关。0：不优化；1：对于 LIKE 表达式首尾存在通配符的情况，优化为 POSITION()函数；

这里把like_opt_flag设置为1就好（默认就是1）

设置方法：

SP_SET_PARA_VALUE(1,'like_opt_flag',1);

然后根据参数like_opt_flag的说明来创建索引：

create index idx_1 on "E9"."WORKFLOW_REQUESTBASE"(position('zss',requestnamenew));

（3）优化后的执行计划和ET

对比优化前后发现，创建的索引已经生效了；

GAN HUO

总结

1）达梦的执行计划和ET是SQL调优的高效工具；

2）创建联合索引时，要根据过滤性来选择，把过滤性好的放在前面；

等值和大于或者小于条件，要把等值条件放在前面；

3）注意字段的类型，如果发生了隐式转换，是不使用索引的

4）对于like查询，达梦数据库有like_opt_flag参数可以进行对应的优化，首尾百分号的情况，可以优化为POSITION()函数；

好，以上是本次分享内容，希望能给大家带来帮助。

往期干货回顾

【内容】：刘江

【编辑】：王

达梦

文章转载自达梦E学，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

干货攻略 | 浅谈达梦SQL调优——执行计划和ET

评论