突破批处理瓶颈：KingbaseES并行DML技术如何榨干多核CPU性能

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 编写。