32 核服务器跑批，只有一个核在干活，其他 31 个核在"围观"。这不是笑话，是串行 DML 的真实写照。
引言：被"单核"锁死的跑批效率
在某大型银行的业务跑批中，DBA 团队面临一个棘手挑战：一个典型的INSERT INTO ... SELECT ...复杂关联语句，涉及基表数据量高达1.7 亿行。
痛点现象：尽管服务器配置了 32 核高性能 CPU 和高速 SSD 存储，但在执行该语句时，仅有一个 CPU 核心处于繁忙状态（利用率 100%），其他核心全部闲置。
业务后果：串行模式下，3000 万行数据的单表插入耗时约 97 秒，上亿行的多表关联插入时间被拉长至数小时，严重威胁跑批任务在业务窗口期内完成。
这正是典型的单进程执行瓶颈。在海量数据面前，单核算力已触及物理天花板。金仓数据库 KingbaseES（KES）的并行 DML（PDML）技术，正是打破这一僵局的利器。
一、KES 的并行"重型武器库"
1.1 Leader + Worker 架构
KES 的 PDML 架构基于成熟的"Leader 进程 + Worker 进程"模型：
- Leader 进程：负责任务分解、Worker 调度和结果汇总
- Worker 进程：并行执行实际的数据扫描、计算和写入
1.2 两种执行计划模型
| 计划模型 | 定位 | 原理 | 适用场景 |
|---|---|---|---|
| MGQ(Modify-Gather-Query) | 查询并行 | 查询部分由多个 Worker 并行执行，结果汇总至 Leader 后由 Leader 单进程完成修改 | "查多改少"的报表分析场景 |
| GMQ(Gather-Modify-Query) | 全领域并行 | 查询和修改任务同步分解，每个 Worker 独立完成所属部分的查询和写入 | 海量数据写入、批处理场景 |
GMQ 是 KES 真正的杀手锏。在 GMQ 模式下，索引维护、约束检查等 CPU 密集型任务被均匀摊派给多个 Worker。实验证明，GMQ 的性能收益伴随并行度增加呈近似线性提升，最高可达 74% 的增益。
二、分步实操：开启 PDML 高速模式
2.1 深度调优：消除底层 I/O 争抢
-- 开启 DML 并行总开关（Session 级别） SET enable_parallel_dml = on; -- 配置并行 Worker 资源池 SET max_parallel_workers = 16; SET max_parallel_workers_per_gather = 8; -- 性能"加速剂"：优化 WAL 写入性能 SET wal_buffers = '512MB'; -- 增加日志缓冲区，防止前台写日志阻塞 SET checkpoint_timeout = '1d'; -- 延长检查点，避免跑批中途频繁刷盘 SET synchronous_commit = off; -- 追求极致速度时关闭同步提交这三个 WAL 参数调优是让并行 Worker 无障碍高速写入的关键，确保并行效率不被 I/O 等待"稀释"。
2.2 用 Hint 引导优化器生成 GMQ 计划
在 KES 中，可以通过语句级 Hint 精准控制并行行为：
-- 对目标表 target_tab 和查询部分同时开启 8 并行 INSERT /*+ parallel(target_tab, 8) */ INTO target_tab SELECT /*+ parallel(8) */ t1.id, t2.info FROM source_tab1 t1 INNER JOIN source_tab2 t2 ON t1.id = t2.id WHERE t1.batch_no = '20241027';KES 的 Hint 语法高度兼容主流商业数据库，降低了迁移成本。
2.3 并行安全性排查
KES 在优化层会自动进行安全性检查。如果目标表存在以下情况，系统将回退到串行模式：
- 触发器（Trigger）——目标表拥有触发器时，为保证逻辑一致性，PDML 被禁用
- 外键约束——涉及自引用、级联删除或延迟约束的外键
- 不安全函数——在 CHECK 约束或生成列中使用了非并行安全函数
DBA 需提前知晓这些限制，在跑批前做好表结构审查。
三、效果验证：量化性能提升
3.1 极速写入能力
在 2.6 亿行数据的多表关联插入测试中：
| 场景 | 串行模式 | 8 并行模式 | 提升比例 |
|---|---|---|---|
| 多表关联插入 | 约 8 分钟 | 约 2 分钟 | 74% |
3.2 索引维护加速
目标表带有索引时，传统数据库的 MGQ 计划性能会严重衰减。而 KES 的 GMQ 模式让索引插入也实现了并行化。测试显示，带索引插入场景下，KES 比传统模式快了 4 倍以上。
3.3 资源利用率监控
- CPU：各工作进程负载均衡，整体 CPU 利用率从 3% 提升至 30% 以上（视并行度而定）
- I/O：磁盘利用率可达 100%，真正榨干了 SSD 的 IOPS 潜力
四、最佳实践总结
- 跑批前调优 WAL 参数——
wal_buffers、checkpoint_timeout、synchronous_commit是并行的基础保障。 - 用 Hint 精准控制并行度——不同 SQL 分配不同并行度，避免资源争抢。
- 关注安全性限制——触发器、外键、不安全函数会回退到串行模式。
- 带索引场景用 GMQ——KES 的 GMQ 让索引插入也实现并行，性能远超 MGQ。
- 监控资源利用率——并行度不是越高越好，找到 CPU 和 I/O 的平衡点。
总结
金仓数据库 KES 的 PDML 技术不仅是简单的"任务拆分"，它是在保证事务强一致性的前提下，对数据库内核的一次深度性能挖掘。
通过 GMQ 全领域并行计划，企业无需频繁升级硬件，即可处理更庞大的业务数据集。对于追求高可用、高性能的现代企业而言，KES 的 PDML 技术无疑是加速核心跑批业务的最优解。
本文基于金仓数据库 KingbaseES V9 编写。
