达梦数据库SQL执行计划深度解读与性能优化实战指南

1. 从一次真实的慢查询排查说起

那天下午，监控系统突然告警，一个核心报表的生成时间从平时的3秒飙升到了近2分钟。业务方电话直接打到了我这里，语气里满是焦急。登录到达梦数据库服务器，第一件事就是抓取当前正在执行的慢SQL。当看到那条熟悉的、原本运行良好的多表关联查询语句时，我心里咯噔一下。没有新增数据，没有修改代码，问题出在哪？我立刻调出了这条SQL的执行计划。计划显示，原本应该走索引的NEST LOOP（嵌套循环）连接，不知为何变成了全表HASH JOIN（哈希连接），其中一个超过百万行的大表被选作了哈希构建表，瞬间耗光了临时表空间，性能断崖式下跌。

这个场景，相信每一位和达梦数据库（DM）打过交道的DBA或开发都不会陌生。SQL优化不是纸上谈兵，它始于对执行计划的精准解读。执行计划就像是数据库引擎的“思维导图”，它清晰地告诉你，为了得到结果，数据库打算先做什么、后做什么、用什么方法做。看不懂它，优化就无从谈起；看懂了它，你就能像医生看X光片一样，直击SQL性能的病灶。本文将结合我多年处理达梦数据库性能问题的实战经验，抛开晦涩的理论，直接带你上手如何获取、解读执行计划，并基于此进行有的放矢的优化。

2. 获取执行计划：不止是EXPLAIN

在动手优化之前，你必须先拿到SQL的执行计划。在达梦中，主要有三种方式，每种都有其特定的使用场景和“坑点”。

2.1 基础武器：EXPLAIN 命令

这是最常用、最直接的方式。在管理工具（如DM管理工具、DBeaver）或命令行中，在SQL前加上EXPLAIN即可。

EXPLAIN SELECT a.order_id, b.customer_name, SUM(c.amount) FROM orders a JOIN customers b ON a.customer_id = b.customer_id JOIN order_details c ON a.order_id = c.order_id WHERE a.create_date > DATE '2023-01-01' GROUP BY a.order_id, b.customer_name;

执行后，你会得到一个文本格式的执行计划输出。这里有一个关键细节：EXPLAIN默认生成的是预估的执行计划。它基于统计信息（如表的行数、索引的选择性）来计算成本，并选择它认为最优的路径。但“预估”和“实际”可能有差距，尤其是当统计信息过时或分布不均时。我遇到过很多次，EXPLAIN显示完美走索引，实际跑起来却是全表扫描，根源就是统计信息太久没更新。

2.2 实战利器：EXPLAIN FOR 与动态性能视图

要看到SQL实际执行时的计划，尤其是在它已经跑起来的时候，就需要用到EXPLAIN FOR和动态性能视图。

方法一：EXPLAIN FOR先获取会话的SESSID：

SELECT SESSID FROM V$SESSIONS WHERE STATE='ACTIVE' AND SQL_TEXT LIKE '%你的SQL关键词%';

然后使用该SESSID：

EXPLAIN FOR SESSID = 123456; -- 替换为实际的SESSID

这能输出该会话当前正在执行语句的实际计划，对于诊断正在发生的慢查询极其有用。

方法二：查询V$SQL_PLAN和V$SQL_PLAN_DETAIL当SQL执行完毕后，其执行计划会被缓存。你可以通过以下关联查询来获取：

SELECT * FROM V$SQL_PLAN p, V$SQL_PLAN_DETAIL d WHERE p.ADDRESS = d.ADDRESS AND p.HASH_VALUE = d.HASH_VALUE AND p.SQL_TEXT LIKE '%你的SQL关键词%' ORDER BY p.ADDRESS, p.HASH_VALUE, d.PLAN_ID;

V$SQL_PLAN_DETAIL包含了更详细的执行步骤信息，如访问的表、索引、连接方法等。这里有个经验：有时你会发现同一条SQL有多个ADDRESS和HASH_VALUE，这可能是因为SQL文本有细微差别（如空格、大小写），导致数据库认为是不同的语句，分别进行了硬解析和缓存。

2.3 图形化辅助：管理工具与第三方工具

对于复杂的执行计划，文本阅读比较费力。达梦自带的DM管理工具可以将EXPLAIN的结果以图形化方式展示，节点之间的流向、成本占比一目了然，非常适合初步分析。此外，像DBeaver这类通用的数据库客户端，在连接达梦后（需正确配置JDBC驱动），也支持图形化显示执行计划，对于习惯使用这类工具的开发者来说更加方便。

注意：图形化工具虽好，但有时会隐藏一些底层细节。在进行深度优化时，我仍然建议结合文本计划一起看，特别是V$SQL_PLAN_DETAIL中的具体操作符和谓词信息。

3. 拆解执行计划：读懂操作符的“语言”

拿到一份文本执行计划，你可能会被一堆诸如NSET2、PRJT2、SLCT2、HASH2 INNER JOIN、CSCN2、SSEK2等术语搞得头晕。别慌，我们来逐一拆解。达梦的执行计划是树形结构，缩进代表层级，通常从最内层（叶子节点）往最外层（根节点）阅读。

3.1 核心操作符详解

1. NSET(Nested Set): 这是计划树的根节点，表示整个查询的结果集收集。它本身不进行数据操作，只是协调其子节点的执行。
2. PRJT(Project): 投影操作。负责从子节点传递上来的行中，选择（投影）出最终查询需要的列。例如，SELECT a, b FROM t，就会有一个PRJT节点来过滤掉其他列。
3. SLCT(Select): 选择操作。对应SQL中的WHERE子句，根据条件过滤行。
4. JOIN系列: 描述表连接方式，这是优化重中之重。
   • NEST LOOP INDEX JOIN: 嵌套循环索引连接。适用于驱动表（外层循环）结果集较小，且内层表连接字段有高效索引的情况。它是逐行匹配的。
   • HASH JOIN: 哈希连接。通常用于没有高效索引或结果集较大的等值连接。它会选择一个小表（或过滤后的小结果集）在内存中构建哈希表，然后扫描大表进行探测。风险点：如果优化器错误地选择了大表作为哈希构建表，会消耗大量内存和临时空间，导致性能骤降。这正是我开篇遇到的问题。
   • MERGE JOIN: 归并连接。要求两个输入集在连接键上都是有序的。如果表上有合适的索引，或者前序步骤（如SORT）已经排好序，可能会选择此方式。
5. 表扫描方式:
   • CSCN(Cluster Scan): 聚簇扫描（全表扫描）。顺序读取表的所有数据页。
   • SSEK(Secondary Index Seek): 二级索引查找。通过非聚簇索引定位到rowid，再回表获取数据。
   • CSEK(Cluster Index Seek): 聚簇索引查找。如果表是聚簇表（索引组织表），通过聚簇索引直接定位数据。
   • BLKUP(Bookmark Lookup): 回表操作。当使用SSEK后，需要根据索引中的rowid去数据块中取出完整的行数据时出现。
6. SORT和HAGR(Hash Aggregate) /SAGR(Sort Aggregate): 排序和聚合操作。GROUP BY、DISTINCT、ORDER BY可能会引发这些操作。HAGR在内存中哈希聚合，适合分组键区分度高的场景；SAGR先排序再聚合，当分组数量极大或内存不足时可能被选用。

3.2 关键字段解读

执行计划中每一行都附带重要信息：

• #CSCN2: [1, 1000, 4]: 这里的[1, 1000, 4]是[估算行数, 估算代价, 输出行宽度]。估算行数是优化器认为该步骤将输出的行数，与实际行数的偏差是导致错误计划的主要原因之一。
• predicates: 显示该步骤应用的过滤条件。检查这里是否有效利用了索引。
• access predicates: 索引访问谓词，说明利用索引的哪些列进行查找。
• filter predicates: 过滤谓词，在访问到数据后进行的额外过滤。

一个简单的分析流程：从最内层缩进的操作开始看，看它扫描了哪个表（TAB字段），用什么方式扫描的（CSCN还是SSEK），估算行数是否合理。然后一层层往外，看连接方式和顺序，重点关注JOIN节点的类型和估算代价。最终，成本最高的那个节点（COST值最大），往往就是性能瓶颈所在。

4. 基于执行计划的优化实战

看懂计划只是第一步，如何根据计划中的“不良信号”进行优化，才是核心价值所在。

4.1 场景一：索引失效与全表扫描

问题特征：执行计划中出现大量CSCN（全表扫描），而你认为应该走索引。排查与解决：

1. 检查谓词：首先看SLCT或扫描操作符的predicates。确保WHERE子句中的列确实有索引，并且谓词形式允许使用索引。例如，对索引列使用函数WHERE UPPER(name) = 'ABC'、进行数学运算WHERE amount*2 > 100，或者使用!=、NOT IN，都可能导致索引失效。
2. 检查统计信息：执行DBMS_STATS.GATHER_TABLE_STATS('模式名','表名');更新统计信息。优化器严重依赖统计信息来判断是走索引快还是全表扫描快。如果统计信息显示表很小，或者索引列的数据分布极度倾斜（比如90%的值都是同一个），优化器可能认为全表扫描更划算。
3. 检查索引选择性：创建一个高选择性的索引才有意义。选择性 = 不同值数量 / 总行数。比值越接近1，选择性越好。为status这种只有‘Y’，‘N’两种值的列建索引，通常效果甚微。
4. 使用HINT强制索引（慎用）：如果确信索引更优，而优化器顽固不化，可以尝试使用HINT。例如：SELECT /*+ INDEX(t idx_name) */ * FROM t WHERE name = 'xxx';。但这是最后的手段，因为数据分布变化后，强制索引可能反而更糟。务必在测试环境充分验证。

4.2 场景二：错误的连接顺序与连接方式

问题特征：多表连接时，执行计划选择的驱动表不合适，或者该用NEST LOOP却用了HASH JOIN，导致性能低下。排查与解决：

1. 分析驱动表：在NEST LOOP中，驱动表应该是结果集小、过滤条件强的表。检查执行计划，看是否把小结果集的大表放在了外层。你可以通过改变SQL写法来“暗示”优化器，例如将筛选条件最严格的表放在FROM子句首位（并非总是有效），或者使用/*+ LEADING(t1 t2) */HINT来指定连接顺序。
2. 评估HASH JOIN的构建表：在HASH JOIN中，内存中构建哈希表的应该是较小的那个结果集。如果执行计划显示大表被选为构建表（HASH JOIN的左子节点通常是构建表），这将是灾难性的。解决方法是确保连接条件中的小表有高效的过滤条件（好的WHERE子句），或者考虑为该表在连接列上建立索引，促使优化器选择NEST LOOP。
3. 检查连接条件索引：对于NEST LOOP，内层表的连接列必须有索引。对于HASH JOIN，虽然不强制要求索引，但如果在连接前内层表能有索引快速过滤掉大量数据，同样能极大提升性能。

4.3 场景三：昂贵的排序与聚合

问题特征：执行计划中出现SORT或SAGR，且代价（COST）非常高，尤其是在处理大量数据时。排查与解决：

1. ORDER BY或GROUP BY的列是否与索引顺序一致？如果经常按(create_date, region)分组或排序，那么创建一个(create_date, region)的复合索引，数据库可能直接利用索引的有序性来避免排序操作（即“索引覆盖排序”）。
2. 是否真的需要所有数据排序？前端分页查询时，常写SELECT * FROM t ORDER BY id LIMIT 20。如果id有索引，这很快。但如果写成SELECT * FROM t ORDER BY name LIMIT 20，而name无索引，数据库会先对全表排序再取前20条，极其低效。确保排序列有索引。
3. 考虑使用HAGR代替SAGR：如果GROUP BY导致SAGR，可以尝试调大HAGR_BUF_GLOBAL_SIZE等内存参数，使得哈希聚合能在内存中完成，但需权衡内存消耗。

4.4 场景四：子查询与视图的性能陷阱

问题特征：执行计划显示对视图或子查询进行了物化（临时结果集），或者子查询被重复执行（DEPENDENT SUBQUERY）。排查与解决：

1. 将相关子查询重写为JOIN：很多情况下，EXISTS、IN子查询可以等价地改写为JOIN，优化器能更好地为JOIN选择执行计划。例如：

   -- 原语句 SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'VIP'); -- 改写为 SELECT o.* FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.status = 'VIP';

2. 谨慎使用视图：视图在逻辑上简化了查询，但物理上可能是一个“黑盒”。优化器有时无法将外层查询的条件“下推”（Push Down）到视图内部，导致视图先全量计算，再进行过滤。对于复杂视图，考虑将其逻辑直接写入主查询，或使用达梦的“视图合并”优化（需评估）。
3. 使用WITH子句（公共表表达式）的考量：WITH CTE AS (...)可以提高可读性，但在达梦中，CTE可能会被物化为临时表。如果CTE数据量小且被多次引用，这是好事；如果数据量大，且只引用一次，则可能增加额外开销。需要根据执行计划判断。

5. 高级调优：并行执行与参数干预

当单条SQL优化到极致后，还可以从更宏观的层面提升性能。

5.1 并行查询（PQO）的启用与把控

达梦支持并行执行计划，对于大表扫描、大量数据连接或聚合操作，并行化能充分利用多核CPU资源。

• 检查是否启用：执行计划中操作符带有P标识（如PCSCN），即表示并行扫描。
• 如何启用：
  • 会话级：SET ENABLE_PARALLEL_DML = 1;(DML并行) /ALTER SESSION ENABLE PARALLEL QUERY;
  • 语句级：使用HINT，SELECT /*+ PARALLEL(t, 4) */ ... FROM t;指定对表t使用4个并行度。
• 注意事项：并行不是银弹。它会增加CPU和内存开销，对于大量短小查询，开启并行反而会降低整体吞吐量。并行度（DOP）设置需谨慎，一般不建议超过CPU物理核心数。对于OLTP型的高并发短事务，通常关闭并行。

5.2 关键优化器参数的影响

达梦数据库有一些初始化参数，能影响优化器的全局行为：

• OPTIMIZER_MODE: 优化器模式。通常保持默认（ALL_ROWS）即可，它倾向于获得最佳吞吐量的计划。在某些交互式场景，可尝试设置为FIRST_ROWS，让优化器优先考虑快速返回前几行。
• USE_PLN_POOL: 是否使用计划缓存。生产环境务必开启（1），避免相同的SQL反复进行硬解析。
• PK_WITH_CLUSTER: 主键是否自动创建聚簇索引。理解聚簇索引（表数据按索引顺序物理存储）和非聚簇索引（索引单独存储，存的是rowid）的区别，对设计高性能表结构至关重要。

修改这些参数需要重启数据库实例，影响全局。切忌在生产环境盲目调整。任何参数变更都应在测试环境基于真实负载进行验证。

6. 构建持续优化的闭环：工具与习惯

SQL优化不是一次性的任务，而是一个持续的过程。

1. 建立慢SQL监控：定期从达梦的动态性能视图V$LONG_EXEC_SQLS或V$SQL_HISTORY中抓取执行时间长、逻辑读/物理读高的SQL。这是发现潜在性能问题的源头。
2. 使用AWR/ASH报告（如果版本支持）：达梦数据库的企业版通常提供类似Oracle AWR的性能报告工具。它能提供特定时间段内的系统负载、TOP SQL、等待事件等全景信息，是进行深度性能分析的利器。
3. 制定SQL审核规范：在开发阶段介入，对复杂查询、多表连接、大数据量操作进行执行计划审查，避免有性能隐患的SQL进入生产环境。
4. 定期更新统计信息：为核心表设置定时任务，在业务低峰期（如凌晨）自动收集统计信息。对于数据变化剧烈的表，收集频率需要更高。
5. 绑定变量与计划稳定性：对于高并发OLTP应用，务必使用绑定变量（如WHERE id = ?），避免因字面值不同导致的大量硬解析和SQL注入风险。但也要注意，有时绑定变量可能导致“绑定变量窥探”问题，即第一次执行时传入的值生成的计划，不适用于后续传入的其他值。达梦有相应的参数和HINT来管理此行为。

回到开头的那个案例，我通过分析执行计划，迅速定位到是统计信息陈旧导致优化器错估了中间结果集的大小，进而选择了错误的连接顺序和方式。在紧急情况下，我使用/*+ LEADING(A B) USE_NL(B) */HINT强制了正确的连接顺序和嵌套循环方式，让报表暂时恢复正常。随后，在业务低峰期，我对相关表进行了全面的统计信息收集，并建立了定期更新任务，从根本上解决了问题。

解读执行计划，就像是与数据库优化器对话。它告诉你它的“想法”，而你需要基于对数据特性、业务逻辑和系统资源的理解，去判断这个“想法”是否合理，并在必要时巧妙地引导它。这个过程没有绝对的公式，需要的是不断的实践、观察和思考。每一次成功的优化，不仅解决了眼前的问题，更是对你数据库知识体系的一次加固。