达梦SQL调优 |
您所在的位置:网站首页 › 表格eles和et的区别 › 达梦SQL调优 |
达梦的执行计划 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管理员手册》。 达梦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: 进入次数 优化案例 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()函数; |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |