使用SQLark分析达梦慢SQL执行计划的一次实践

最近刚参加完达梦的 DCP 培训与考试，正好业务系统有个 sql 查询较慢，就想着练练手。

在深入了解达梦的过程中，发现达梦新出了一款叫 SQLark 百灵连接的工具。

我首先去官网大致浏览了下。虽然 SQLark 在功能深度上不如 DM Manager 和 PL/SQL，但常用的基础功能都有，还能很好的兼容 DM 和 Oracle，满足我的日常使用需求。

SQLark 工具里有个“执行计划分析模式”的功能，很适合用于分析我的慢 SQL（不用我粘贴到 Notepad++ 里分析）。

在这里我记录下学习达梦执行计划，并分析的过程。

👉 前往SQLark官网：www.sqlark.com 注册永久免费！

业务场景

软件控制硬件设备，处理一个作业任务，一个作业任务对应plc_rin表的一条记录。

plc_rin_temp表记录的是该硬件做任务期间的温度监控信息。温度是每隔3秒采集一次。

所以plc_rin与plc_rin_temp是一对多的关系。

业务场景

plc_rin.id = plc_rin_temp.rin_id

关联关系

大致说下业务的sql实现：

先对任务id进行分组，获取plc_rin_temp表每个rin_id的最新的一条数据。

然后join关联，获取到每个rin_id的最新采集的两条记录（每次采集，不同模块的采集时间是一致的）

最后任务表plc_rin左连接上面的结果集。

selectp."rin_user_name",p."start_time",p."end_time",p."rin_wheel_num",a.*from"plc_rin" pleft join (selectt1.*from"plc_rin_temp" t1inner join (selectmax("temp_minute") as "temp_minute","rin_id"from"plc_rin_temp"group by"rin_id") t2 on t1."temp_minute" = t2."temp_minute"and t1."rin_id" = t2."rin_id") a on p."id" = a."rin_id"
wherep."id" in ('44dc5165-93f8-4418-8407-245f1f94b192','5ea6b18c-f7c0-400f-a33e-1b778299d163'
);

查询结果大概就是这样的：每个rin_id对应两条最新的温度采集数据。

SQL慢问题

当plc_rin和plc_rin_temp数据量越来越多后，该sql的执行效率就越低，甚至好几秒才能加载出来。对于当前我这种对数据库优化研究不深的开发人员来说，这是一次很好的机会，从一个DBA的角度来优化sql。

执行计划分析

1. 什么是执行计划

在数据库管理中，执行计划是查询优化器根据查询语句的结构和表的统计信息生成的一种操作指南，用于指导数据库引擎执行查询操作。它描述了数据库引擎如何访问表、使用索引、连接表以及进行其他操作来获取查询结果。

简单点说，执行计划是 SQL 语句的执行方式，由查询优化器为语句设计的执行方式，交给执行器去执行。

通过执行计划，可以了解查询的执行过程，找出性能瓶颈，从而进行优化。

2. 如何查看执行计划

使用 EXPLAIN 可以打印出语句的执行计划。
或者直接点击【执行计划】按钮。

一开始不理解这些字符和数字分别代表什么，可以切换为表格形式：

3. 执行计划分析模式

进入执行计划分析模式，可以更好的查看和分析执行计划信息。

因为默认没有展示附加信息，我们可以勾选是否展示。这点挺人性化的，因为有时候分析的时候其实并不希望太多的信息，很多信息会干扰查看。

4. 如何分析执行计划

1）执行计划操作符

列出几个我们执行计划中出现的操作符，也是比较常见的操作符。

想看所有操作符，可以去官方网站：

https://eco.dameng.com/document/dm/zh-cn/pm/dm8-admin-manual-appendix4.html

2）执行计划顺序

缩进越多的越先执行，同样缩进的上面的先执行，下面的后执行，上下的优先级高于内外。

PS: 希望SQLark工具的后续版本，能提供查看执行计划的顺序

剧透：查看执行计划顺序的功能将在下个版本上线~

3）执行计划代价

每个操作符后面会有一个三元组。例如CSCN2: [1, 3960, 56]。

[1, 3960, 56]就是一个三元组，其中 3 个数字分别表示该操作符的估算代价、输出结果集和行数据处理长度。

分析结论

因为这是做的本地测试，所以数据量不多。plc_rin表有50条记录，plc_rin_temp有3960条记录。

从执行计划中的CSCN2: [1, 3960, 56]上可以看出，我的sql查询，是做了全表扫描的，而且因为join的原因，做了两次。

搜索执行计划中是否含 CSCN 操作符

由于业务关系和我的水平限制，尝试过对sql进行改写优化，但都不大理想，例如下面这种：

将过滤条件下推

selectp."rin_user_name",p."start_time",p."end_time",p."rin_wheel_num",a."temp_type",a."temp_start",a."temp_bearing",a."temp_rise",a."temp_minute",a."rin_id"
from"plc_rin" pleft join (selectt1.*from"plc_rin_temp" t1inner join (selectmax("temp_minute") as "temp_minute","rin_id"from"plc_rin_temp"where"rin_id" in ('44dc5165-93f8-4418-8407-245f1f94b192','5ea6b18c-f7c0-400f-a33e-1b778299d163','fa09591c-db5b-4497-8c78-51615b12179d','74e03635-c912-433f-a00f-b76c5c9aa4df','062302b8-13c8-4412-a43a-35d5ef740a43','5317ea2f-c6bf-482b-989e-c8a78bb6ece5')group by"rin_id") t2 on t1."temp_minute" = t2."temp_minute"and t1."rin_id" = t2."rin_id") a on p."id" = a."rin_id"
;

执行计划是这样的：

发现改写后，反而代价更高了。只能考虑其他优化方式。

因为plc_rin_temp表会频繁插入数据，所以也不建议创建索引。当前有两种方式：

• 就是利用触发器，将需要的数据提取出来，存入另一张表中。

• 就是做分表，因为业务关系，基本当天的任务当天就处理完了，处理完的数据基本就是历史数据了，不会处理了。我们可以将plc_rin_temp分为两个表，一个当前数据表，一个历史数据表。当前数据表的数据处理完后将数据转入历史数据表。

我自己比较倾向于第二种方式。如果大家有更好的方式，敬请指教，先谢为敬！

👉 前往SQLark官网：www.sqlark.com 免费下载体验！