别再死记硬背了！达梦执行计划操作符实战速查手册（附SQLark造数据技巧）
达梦执行计划操作符实战指南：从困惑到精通的调优之路
每次面对达梦数据库执行计划中那些晦涩难懂的操作符缩写，你是否感到一阵头疼？SAGR、HAGR、BLKUP这些看似简单的字母组合背后，隐藏着SQL性能优化的关键密码。本文将彻底改变你阅读执行计划的方式——不再死记硬背，而是通过实战场景快速定位问题，掌握每个操作符背后的调优逻辑。
1. 执行计划快速解析方法论
达梦数据库的执行计划就像一份SQL执行的"体检报告"，而操作符就是这份报告中的关键指标。传统的学习方式往往要求我们记住每个操作符的全称和含义，但这在实际工作中效率极低。更高效的方法是建立一套模式识别系统：
操作符命名规律：
- 结尾带
2的版本（如NSET2、PRJT2）是达梦7之后的优化版本 - 前缀字母揭示操作类型：
C开头：聚集索引相关（CSCN、CSEK）S开头：二级索引相关（SSCN、SSEK）A/H/S+AGR：不同类型的聚合计算
- 结尾带
代价三元组解读技巧：
-- 示例执行计划节点 3 | CSCN2 | [1, 1246, 397]这组数字分别表示：
- 预估耗时（毫秒）
- 输出行数
- 输出数据量（字节）
实际优化时，重点关注行数估算是否准确。当
预估行数与实际行数差异超过10倍时，通常意味着统计信息需要更新。
- 执行顺序快速判定：
- 无并行：从最内层节点开始阅读
- 有并行：从上往下阅读
- 图形化工具中可用"前进按钮"逐步查看执行流程
2. 核心操作符实战图谱
我们不再按字母顺序罗列操作符，而是根据性能影响程度分级讲解，并配典型场景和优化方案。
2.1 高成本操作符及优化方案
| 操作符 | 全称 | 出现场景 | 优化策略 | 风险等级 |
|---|---|---|---|---|
| CSCN | 聚集索引全扫描 | 无可用索引的查询 | 添加WHERE条件字段索引 | ★★★★ |
| HAGR | Hash分组聚合 | GROUP BY非索引列 | 改为索引列或创建函数索引 | ★★★ |
| BLKUP | 回表操作 | 通过二级索引查询非索引列 | 使用覆盖索引或减少返回列 | ★★ |
典型优化案例：
-- 优化前（出现BLKUP） SELECT * FROM orders WHERE user_id = 100; -- 优化后（使用覆盖索引） CREATE INDEX idx_user_cover ON orders(user_id, order_date, amount); SELECT user_id, order_date, amount FROM orders WHERE user_id = 100;2.2 聚合操作符深度解析
达梦有三种聚合计算方式，理解它们的区别对优化GROUP BY查询至关重要：
AAGR(简单聚合)：
- 场景：无GROUP BY的COUNT/SUM等
- 特点：单次全量计算
- 示例：
SELECT COUNT(*) FROM table
HAGR(Hash分组聚合)：
-- 典型HAGR场景（name无索引） EXPLAIN SELECT name, COUNT(*) FROM users GROUP BY name;- 内存消耗大
- 建议：为分组列创建索引转为SAGR
SAGR(流分组聚合)：
- 需要分组列有索引
- 性能比HAGR提升30%-50%
- 检查执行计划确认是否走索引
2.3 索引访问操作符对比
通过一个测试表演示不同索引访问方式：
CREATE TABLE test_index ( id INT PRIMARY KEY, name VARCHAR(50), age INT, INDEX idx_name(name), INDEX idx_age_name(age, name) );执行计划对比表：
| 查询语句 | 预期操作符 | 触发条件 |
|---|---|---|
SELECT * FROM test_index | CSCN | 无过滤条件 |
SELECT name FROM test_index WHERE name LIKE '张%' | SSCN | 覆盖索引查询 |
SELECT * FROM test_index WHERE name = '张三' | SSEK+BLKUP | 二级索引查询非索引列 |
SELECT * FROM test_index WHERE id = 100 | CSEK | 主键查询 |
3. 高效测试数据构建技巧
精准的性能调优需要可重现的测试环境。使用达梦自带的SP_TAB_STAT_INIT初始化统计信息后，还需要合适的数据量来模拟真实场景。
数据构造黄金法则：
- 小表（<1万行）：手工插入即可
- 中表（1万-100万行）：使用CTE递归生成
- 大表（>100万行）：推荐使用存储过程
示例：快速生成10万条测试数据
-- 使用CTE递归生成序列 INSERT INTO user_transactions WITH RECURSIVE temp(id) AS ( SELECT 1 UNION ALL SELECT id+1 FROM temp WHERE id < 100000 ) SELECT id, '用户' || MOD(id, 1000), ROUND(DBMS_RANDOM.VALUE(1, 1000), 2), CASE MOD(id, 3) WHEN 0 THEN '成功' WHEN 1 THEN '失败' ELSE '处理中' END, SYSDATE - MOD(id, 365) FROM temp;重要提示：数据生成后务必执行
SP_TAB_STAT_INIT更新统计信息，否则执行计划可能不准确。
4. 实战调优检查清单
当发现SQL性能问题时，按照以下步骤系统分析执行计划：
定位关键节点：
- 找到执行计划中代价最高的节点（通常在最外层）
- 检查其子节点的操作符类型
操作符诊断：
- 是否出现全表扫描（CSCN）？
- 聚合计算是否使用低效的HAGR？
- 是否存在不必要的回表（BLKUP）？
优化方案选择：
- 添加缺失的索引（优先考虑组合索引）
- 重写SQL使用索引覆盖
- 修改JOIN顺序或方式
验证效果：
- 比较优化前后的执行计划
- 使用
SET STAT TIME ON查看实际执行时间 - 检查逻辑读次数变化
典型优化案例：
-- 优化前（使用HAGR） EXPLAIN SELECT department, COUNT(*) FROM employees WHERE hire_date > '2020-01-01' GROUP BY department; -- 优化后（创建覆盖索引） CREATE INDEX idx_dept_hire ON employees(department, hire_date); -- 执行计划显示变为SAGR记住，执行计划优化不是一次性的工作，随着数据量增长和业务变化，需要定期复查关键SQL的执行计划。我曾经遇到一个报表查询，在数据量达到50万行后执行时间从2秒骤增到30秒，复查发现原本高效的SAGR变成了HAGR，通过调整索引解决了问题。