达梦SQL调优--执行计划和ET

达梦的执行计划

什么是达梦的执行计划？

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

如何查看执行计划

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

在达梦的管理工具中，可以选中需要查看的SQL语句，按下F9键也可以查看它的执行计划。
EXPLAIN FOR可以查看更加详细的执行计划内容。

如何解读达梦的执行计划

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管理员手册》。

达梦ET

什么是ET

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

为什么使用ET

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

怎么使用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: 进入次数

优化案例

案例一

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：

案例二

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()函数；

以上就是本文的全部内容，希望对大家的学习有所帮助，本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文地址：https://blog.csdn.net/yangeoooo/article/details/118575215