某国产数据库首次实现并行 DML：与 Oracle 的简单对比和实践指南

JiekeXu

512人浏览 · 2026-04-02 07:45:54

JiekeXu · 2026-04-02 07:45:54 发布

作者 | JiekeXu 来源 |公众号 JiekeXu DBA之路

如需转载请联系授权 | (个人微信 ID：JiekeXu_DBA)

作者：JiekeXu,江湖人称“强哥”，青学会MOP技术社区主席，荣获Oracle ACE，OpenTenBase ACE，金仓最具价值倡导者KVA，崖山最具价值专家YVP，IvorySQL开源社区专家顾问委员会成员，KWDB社区MVP，墨天轮MVP，墨天轮年度“墨力之星”，拥有OCP/OCM 认证,MySQL 5.7/8.0 OCP认证以及金仓KCM、KCSM证书，TiDB PCTA/PCTP 等其他国产数据库认证证书,欢迎关注我的微信公众号“JiekeXu DBA之路”，然后点击右上方三个点“设为星标”置顶，更多干货文章才能第一时间推送，谢谢！后台回复【加群】添加我微信一起交流学习。

某国产数据库并行 DML 技术解析与实战指南

前 言一、金仓数据库并行 DML 技术深度解析    1.1 并行 DML 的基本原理与架构    1.2 金仓并行 DML 的两种核心执行计划        1.2.1 MGQ计划（Modify-Gather-Query）        1.2.2 GMQ计划（Gather-Modify-Query）    1.3 金仓并行 DML 的关键参数配置    1.4 并行触发条件参数二、Oracle 数据库并行技术全面分析    2.1 Oracle 并行执行的核心架构    2.2 Oracle 并行 DML 的实现机制    2.3 Oracle 并行执行的技术特性        2.3.1 并行粒度（Granule）        2.3.2 数据分发方法三、金仓 KES 与 Oracle 并行DML技术对比分析    3.1 架构设计对比    3.2 易用性和生态系统对比    3.3 适用场景对比分析四、金仓 KES 并行 DML 实战指南    4.1 环境准备与基础配置    4.2 并行 DML 实战示例    4.3 常见问题与解决方案五、总结六、参考链接

前言

在当今大数据的时代，金融、政务等核心业务系统面临着海量数据处理的严峻挑战，传统的串行 DML 执行模式在处理数亿级数据时，常常出现"单核打满、多核闲置"的资源浪费现象，这不仅影响了业务效率，更直接威胁到系统的稳定性和可靠性。笔者在运维 Oracle 的过程中，偶尔也会遇到上亿的大表添加字段并更新值的情况，幸亏 Oracle 有并行 DML(PDML) 技术能够在比较短暂的时间内完成变更，减少了业务停机时间。

在国产数据库领域中，我很少看到或提到并行 DML，不知道是我“坐井观天”的缘故，或者本就是没有呢，集中式数据库中基本没有看到了，昨天还特意看了下达梦数据库的文档并没有并行 DML，而我知道电科金仓 KingbaseES（KES）早在前年的某次内部技术会上和他们开发者沟通已经实现了并行 DML，只是苦于当时没有相关的技术资料，没有深入探索，今天难得有时间且他们发布的最新版本镜像(V009R002C014B0009)也支持了并行 DML，所以想着来体验一番。

一、金仓数据库并行 DML 技术深度解析

1.1 并行 DML 的基本原理与架构

并行查询原理：在说并行 DML 之前，这里先了解一下并行查询的原理，KES 支持通过多核 CPU 并行执行单个 SQL 语句，这一功能被称为并行查询，在优化器评估某个特定查询时，若判断并行执行为最优策略，则会生成包含 Gather 或 GatherMerge 操作节点的查询执行计划。KES 的分析器、重写器以及优化器组件仍按常规流程运作，仅在生成执行计划时触发并行查询机制。在执行计划中，Gather 节点作为其中一个操作符节点，标志着并行处理的开始，当查询执行到达该节点时，会话进程将根据配置参数及成本估算申请一定数量的工作线程（worker processes）。其中，一个特定的 worker 被指定为主工作线程（leader worker），负责协调和汇总其他 worker 线程的查询结果，主工作线程不仅承担协调任务，还会根据实际数据量参与部分并行处理工作。Leader 工作线程与其他工作线程通过动态共享内存实现通信机制。在并行查询过程中，所有其他 worker 进程（包括主工作线程）将各自处理的数据结果写入到共享内存区域中。主工作线程负责从共享内存中读取各 worker 的处理成果，并完成最终结果的汇总操作。整个执行流程如下：

金仓数据库的并行 DML(PDML) 技术基于成熟的" Leader 进程 + Worker 进程"模型，这一架构设计充分考虑了海量数据处理的现实需求。在整个执行过程中，会话进程充当协调器的角色，负责整个并行任务的调度和监控。

核心执行流程总结如下：

1. 用户提交 DML 语句后，优化器评估并行执行的可行性
2. 查询协调器（QC）根据配置参数和成本估算申请工作线程
3. 其中一个 Worker 被指定为主工作线程（Leader Worker），负责协调和汇总
4. 所有 Worker 进程通过动态共享内存实现高效通信
5. 最终结果由 Leader 进程汇总返回给用户

这种架构的优势在于能够充分利用多核 CPU 的计算能力，将单个大型任务分解为多个可并行执行的子任务。

1.2 金仓并行 DML 的两种核心执行计划

金仓数据库提供了两种不同的并行执行计划，针对不同的业务场景进行优化：

1.2.1 MGQ 计划（Modify-Gather-Query）

MGQ 计划采用"查询并行、修改串行"的策略，适合查询密集型场景。在这种模式下：

• 查询（SELECT）部分由多个 Worker 进程并行执行
• 所有 Worker 的结果汇总到 Leader 进程
• 由 Leader 进程单独完成数据修改（INSERT/UPDATE/DELETE）

这种计划特别适合报表分析、数据查询等"查多改少"的业务场景，能够在保证查询效率的同时，降低系统资源占用。

1.2.2 GMQ计划（Gather-Modify-Query）

GMQ 计划是金仓数据库的"王牌"技术，实现了真正的全流程并行：

• 查询和数据修改任务同步拆分给多个 Worker 进程
• 每个 Worker 独立完成查询和对应部分的数据写入
• 索引维护、约束检查等操作均匀分摊给各个进程

根据官方介绍，GMQ 计划的性能收益随并行度增加呈近似线性提升，最高可达 74% 的性能增益，充分榨干了硬件算力。

1.3 金仓并行 DML 的关键参数配置

正确的参数配置是发挥并行 DML 性能的基础，以下是最关键的配置参数：

-- 开启 DML 并行总开关
SET enable_parallel_dml =on;

-- 配置Worker资源池
SET max_parallel_workers = 16; -- 控制整个系统最大的并行工作进程数
SET max_parallel_workers_per_gather = 8;  --限制单个 Gather 节点的最大工作进程数

-- WAL写入优化
ALTER SYSTEM SET wal_buffers = '512MB';  -- 增加日志缓冲区，防止前台写日志阻塞
ALTER SYSTEM SET checkpoint_timeout = '1d'; -- 延长检查点，避免跑批中途频繁刷盘
ALTER SYSTEM SET synchronous_commit = off;  -- 追求极致速度时建议关闭同步提交

参数配置要点说明：

• max_worker_processes: 默认值为 30，取值为 1~2的18次方减一，设置系统支持的最大后台进程数，此参数调整后需要重启数据库生效。
• max_parallel_workers：默认值为 8，控制整个系统最大的并行工作进程数，该数值不能大于 max_worker_processes。
• max_parallel_workers_per_gather：默认值为 2，限制单个 Gather 节点的最大工作进程数，该数值不能超过max_parrellel_workers。
• max_parallel_maintenance_workers: 默认值为 2，最大并行维护操作 worker 数，该数值不能超过max_parrellel_workers。

这 4 个参数之间的关系为：

max_parallel_workers_per_gather + max_parallel_maintenance_workers <= max_parallel_workers <= max_worker_processes

1.4 并行触发条件参数

那么，问题来了多大的表才能并行呢，这里其实和 Oracle 是类似的，有两个参数定义了表和索引的大小，超过了此参数定义的大小之后，便可以使用并行。

• min_parallel_table_scan_size:默认值为 8MB，取值为 0~2GB，当表的存储空间至少大于等于该值，才有可能触发并行。
• min_parallel_index_scan_size：默认值为 512KB，取值为 0~2GB，当索引存储空间至少大于等于该数值，才有可能触发并行索引。

那么可以通过以下语句来获得表、索引的磁盘存储大小：

SELECT sys_size_pretty(sys_relation_size('emp'));

其他并行优化器参数：

• enable_parallel_append:默认值为 on，优化器控制开关，是否允许并行 append。
• enable_parallel_hash: 默认值为 on，优化器控制开关，是否允许并行 hash。
• enable_hint: 此版本（V009R002C014B0009）默认值为 on，低版本默认值为 OFF，优化器控制开关，用于控制 SQL 语句中的 HINT 注释是否生效。
• parallel_setup_cost：默认值为 1000，表示启动 woker process 的启动成本，因为启动 worker 进程需要建立共享内存等操作，属于附带的额外成本。其值越小，数据库越有可能使用并行查询。
• parallel_tuple_cost: 默认值为 0.1，woker 进程处理完后的 tuple 要传输给上层 node，即进程间查询结果的交换成本，即后台进程间传输一个元组的代价。其值越小，数据库越有可能使用并行。
• parallel_leader_participation: 默认值为 on，控制 Gather、Gather merge 节点是否能执行 subplans。

优化器主要根据 max_worker_processes 决定能够开启 worker 进程数后，根据目标表或者索引的大小（min_parallel_table_scan_size、min_parallel_index_scan_size），以及根据 parallel_setup_cost 和 parallel_tuple_cost 算出来的并行总 cost，跟其他不使用并行方案比较后决定是否启用并行，以及本次查询的并行进程数（小于等于 max_parallel_workers）。

二、Oracle 数据库并行技术全面分析

下面简单介绍一下 Oracle 并行技术，感兴趣的朋友可以查看我以前写的并行系列文章《八千字带你了解 Oracle 并行那些事(一)》和《八千字带你了解 Oracle 并行那些事(二)》。

2.1 Oracle 并行执行的核心架构

Oracle 数据库的并行执行采用经典的生产者/消费者模型，其架构设计体现了成熟数据库系统的深厚技术积累。

Oracle 并行执行的关键组件：

• 查询协调器（QC）：负责整个并行语句的协调工作
• 并行执行服务器（PX服务器）：实际执行并行工作的进程
• 数据流操作（DFO）：并行执行的基本工作单元

Oracle 的并行度（DOP）决定了一个操作关联的并行执行服务器个数。默认情况下，DOP的计算公式为：

• 单实例：DOP = PARALLEL_THREADS_PER_CPU × CPU_COUNT
• RAC环境：DOP = PARALLEL_THREADS_PER_CPU × Σ(CPU_COUNT)

2.2 Oracle 并行 DML 的实现机制

Oracle 的并行 DML 支持 INSERT、UPDATE、DELETE、MERGE 四种操作，但其实现有着严格的限制条件。

并行 DML 的启用方式：

-- 12c之前的方式ALTER SESSION ENABLE PARALLEL DML;
INSERT /*+ PARALLEL(16) */ INTO emp1 SELECT /*+ PARALLEL(16) */ * FROM emp WHERE deptno = 30;
-- 12c新增的Hint方式INSERT /*+ ENABLE_PARALLEL_DML PARALLEL(16) */ INTO emp1 SELECT * FROM emp WHERE deptno = 30;

Oracle并行 DML 的重要限制：

• 目标表存在触发器时自动禁用并行DML
• 不支持自参照完整性、删除级联和延迟完整性约束
• 集群表不支持并行 DML
• 临时表不支持并行 UPDATE、DELETE 和 MERGE 操作

2.3 Oracle 并行执行的技术特性

2.3.1 并行粒度（Granule）

Oracle 支持两种并行粒度：

• 块范围粒度：基于表中物理块的范围，提供更好的灵活性和负载均衡
• 分区粒度：基于表的分区结构，并行度受分区数量限制

2.3.2 数据分发方法

Oracle 使用多种数据分发方法优化并行执行：

• 哈希分布：基于哈希函数在消费者间均匀分配工作
• 广播分发：每个生产者将所有行发送给所有消费者
• 范围分布：主要用于并行排序操作
• 混合哈希分布：自适应的分布方法，根据数据量动态选择

三、金仓 KES 与 Oracle 并行DML技术对比分析

3.1 架构设计对比

金仓 KES 数据库的优势：

1. GMQ 计划实现真正的全流程并行，包括索引维护的并行化
2. 共享 group lock 机制巧妙解决多进程写锁互斥问题
3. 对国产硬件和操作系统的深度优化

Oracle 数据库的特点：

1. 成熟稳定的生产者/消费者模型，经过长期实践检验
2. 丰富的并行度控制策略和资源管理机制
3. 与 RAC 环境的深度集成，支持集群级并行

3.2 易用性和生态系统对比

金仓数据库的易用性特点：

• Hint语法高度兼容主流商业数据库，迁移成本低
• 参数配置相对简化，学习曲线平缓
• 完善的国产化生态支持

Oracle数据库的成熟度体现：

• 丰富的并行相关视图（V$PQ_TQSTAT、V$PX_SESSION等）
• 细致的资源控制和监控能力
• 全面的文档和社区支持

3.3 适用场景对比分析

金仓并行 DML 最适合的场景：

1. 政务、金融等国产化要求高的核心业务系统
2. 海量数据跑批和ETL处理
3. 对数据一致性要求极高的OLTP环境

Oracle并行DML的优势场景：

1. 超大规模数据仓库和分析系统
2. 复杂的混合负载环境
3. 全球部署的分布式系统

四、金仓 KES 并行 DML 实战指南

4.1 环境准备与基础配置

硬件环境要求：

• 多核CPU（建议8核以上）
• 充足的内存资源
• 高速存储（SSD推荐）

单机 KES V9R2C14 数据库安装简介

值得一说的是现在 KES V9R2C14 版本可以通过 Kconsole 控制台来创建、删除、管理数据库了，可以通过命令行模式或者图形化模式，非常方便简单。

[root@JiekeXu ~]# mount /home/kingbase/KingbaseES_V009R002C014B0009_Lin64_install.iso /mnt
mount: /dev/loop0 is write-protected, mounting read-only
[kingbase@JiekeXu mnt]$ export LANG=zh_CN.UTF-8
[kingbase@JiekeXu mnt]$ sh setup.sh -i console
Java Version: 11-ea
Now launch installer...
Command line arguments: -console -language chn
================================================================================
欢迎使用KingbaseES安装程序

...省略安装步骤...

================================================================================
恭喜您！安装完成
----


  恭喜您！安装完成

  安装目录：
    /data/KingbaseES/V9


    引导组件:/data/KingbaseES/V9/KESRealPro/V009R002C014/install
    产品手册:/data/KingbaseES/V9/KESRealPro/V009R002C014/doc
    数据库运维工具:/data/KingbaseES/V9/KESRealPro/V009R002C014/SupTools
    数据库服务器:/data/KingbaseES/V9/KESRealPro/V009R002C014/Server
    高可用组件:/data/KingbaseES/V9/KESRealPro/V009R002C014/KingbaseHA
    接口:/data/KingbaseES/V9/KESRealPro/V009R002C014/Interface
    数据库集群部署工具:/data/KingbaseES/V9/KESRealPro/V009R002C014/ClientTools/guitools/DeployTools
    数据库迁移工具:/data/KingbaseES/V9/KESRealPro/V009R002C014/ClientTools/guitools/KDts
    数据库开发工具(CS):/data/KingbaseES/V9/KESRealPro/V009R002C014/ClientTools/guitools/KStudio


如需初始化数据库，请启动Kconsole:
/data/KingbaseES/V9/Server/bin/kconsole.sh --cli

[ Writing the uninstaller data ... ]
[ 命令行安装完成 ]
[kingbase@JiekeXu mnt]$
[kingbase@JiekeXu mnt]$ /data/KingbaseES/V9/Server/bin/kconsole.sh --cli
╔═════════════════════════════════╗
  欢迎使用金仓数据库管控工具
  JDK Version： 1.8.0_202
  PID: 2984
Local: zh
  Features: DB_MODE_ORACLE
╚═════════════════════════════════╝
1) 创建数据库实例
2) 查看数据库实例列表
3) 删除数据库实例
4) 启动/停止数据库实例
5) 添加/移除系统服务
6) 退出程序


初始数据库实例...
初始数据库实例成功
设置数据库参数...
设置数据库参数成功
运行数据库实例...
运行数据库实例成功
修改审计管理员和安全管理员密码...
修改审计管理员和安全管理员密码成功

数据库实例创建完成！

添加系统服务，使用root用户执行如下脚本：
/home/kingbase/.kconsole/add_service_jiekexu.sh
Tips: 请手动创建物理备份，未创建备份可能导致数据丢失且无法恢复!
物理备份脚本：/data/KingbaseES/V9/KESRealPro/V009R002C014/Server/bin/sys_backup.sh
物理备份配置文件：/data/KingbaseES/V9/KESRealPro/V009R002C014/Server/share/sys_backup.conf

[kingbase@JiekeXu~]$ ksql -h localhost -U system -d test -p 52026
用户 system 的口令：
授权类型: 企业版.
输入 "help" 来获取帮助信息.

test=#

数据库并行设置相关参数：

-- 检查当前并行配置
SHOW enable_parallel_dml;

SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;

-- session 级别设置并行
SET enable_parallel_dml = on;  --低版本无此参数会报错，ERROR:  unrecognized configuration parameter "enable_parallel_dml"

SET max_parallel_workers = 16;
SET max_parallel_workers_per_gather = 8;

-- 优化WAL配置
SHOW wal_buffers; 
SHOW checkpoint_timeout;
SHOW synchronous_commit; 

ALTER SYSTEM SET wal_buffers = '512MB';  -- 增加日志缓冲区，防止前台写日志阻塞
ALTER SYSTEM SET checkpoint_timeout = '1d'; -- 延长检查点，避免跑批中途频繁刷盘
ALTER SYSTEM SET synchronous_commit = off;  -- 追求极致速度时建议关闭同步提交

4.2 并行 DML 实战示例

示例 1：基础并行插入操作

show enable_hint;  --此版本默认开启，低版本未开启此参数
SET enable_hint = on;
-- 启用并行DML
SET enable_parallel_dml = on;
--创建表
CREATE TABLE source_tab1 (id BIGINT,ts TIMESTAMP,filler TEXT);
CREATE TABLE source_tab2 (id BIGINT,info TEXT);
--插入数据
INSERT INTO source_tab1 SELECT generate_series(1, 3000000),clock_timestamp(),md5(random()::text);
INSERT INTO source_tab2 SELECT generate_series(1, 3000000),md5(random()::text);

-- 创建目标表和索引
CREATE TABLE target_tab (id BIGINT,info TEXT);
--CREATE INDEX idx_target_id ON target_tab(id);

-- 执行并行插入
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.ts >='2026-04-01 17:42:07';

INSERT 0 275403
时间：840.413 ms

--正常插入
truncate table target_tab;
INSERT INTO target_tab
SELECT  t1.id, t2.info
FROM source_tab1 t1
INNER JOIN source_tab2 t2 ON t1.id = t2.id
WHERE t1.ts >='2026-04-01 17:42:07';

INSERT 0 275403
时间：1214.405 ms (00:01.214)

由此可见，关联查询后正常插入需要 1214.405 ms，并行插入仅需要 840.413 ms，并行执行时间缩短近三分之一。

示例 2：复杂业务场景的并行

-- 创建订单主表CREATE TABLE orders (    order_id BIGINT PRIMARY KEY,    customer_id BIGINT NOT NULL,    order_date DATE NOT NULL,    total_amount DECIMAL(15,2) NOT NULL DEFAULT 0,    order_status VARCHAR(20) DEFAULT 'PENDING',    created_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,    updated_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP);-- 创建订单明细表CREATE TABLE order_details (    detail_id BIGSERIAL PRIMARY KEY,    order_id BIGINT NOT NULL,    product_id BIGINT NOT NULL,    product_name VARCHAR(200) NOT NULL,    quantity INTEGER NOT NULL CHECK (quantity > 0),    unit_price DECIMAL(10,2) NOT NULL CHECK (unit_price >= 0),    line_amount DECIMAL(12,2) GENERATED ALWAYS AS (quantity * unit_price) STORED,    created_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,    CONSTRAINT fk_order_details_order FOREIGN KEY (order_id) REFERENCES orders(order_id));-- 创建订单临时表（用于数据准备）CREATE TABLE staging_orders (    order_id BIGINT PRIMARY KEY,    customer_id BIGINT NOT NULL,    customer_name VARCHAR(100) NOT NULL,    order_date DATE NOT NULL,    batch_date VARCHAR(8) NOT NULL,    region VARCHAR(50),    sales_person VARCHAR(50),    order_priority VARCHAR(20) DEFAULT 'NORMAL');-- 创建订单明细临时表CREATE TABLE staging_order_details (    order_id BIGINT NOT NULL,    product_id BIGINT NOT NULL,    product_name VARCHAR(200) NOT NULL,    category VARCHAR(50) NOT NULL,    quantity INTEGER NOT NULL,    unit_price DECIMAL(10,2) NOT NULL,    discount DECIMAL(5,2) DEFAULT 0,    batch_date VARCHAR(8) NOT NULL,    CONSTRAINT pk_staging_details PRIMARY KEY (order_id, product_id));
-- 插入订单临时数据INSERT INTO staging_orders (order_id, customer_id, customer_name, order_date, batch_date, region, sales_person, order_priority)VALUES (1001, 501, '张三', '2024-10-27', '20241027', '华东', '销售A', 'HIGH'),(1002, 502, '李四', '2024-10-27', '20241027', '华北', '销售B', 'NORMAL'),(1003, 503, '王五', '2024-10-27', '20241027', '华南', '销售C', 'LOW'),(1004, 501, '张三', '2024-10-27', '20241027', '华东', '销售A', 'HIGH'),(1005, 504, '赵六', '2024-10-27', '20241027', '西南', '销售D', 'NORMAL'),(1006, 505, '钱七', '2024-10-26', '20241026', '西北', '销售E', 'HIGH'),(1007, 506, '孙八', '2024-10-26', '20241026', '东北', '销售F', 'NORMAL');
-- 验证插入结果SELECT COUNT(*) AS order_count FROM staging_orders WHERE batch_date = '20241027';
-- 插入订单明细数据INSERT INTO staging_order_details (order_id, product_id, product_name, category, quantity, unit_price, discount, batch_date)VALUES (1001, 2001, '笔记本电脑', '电子产品', 1, 5999.00, 0.05, '20241027'),(1001, 2002, '无线鼠标', '电子产品', 2, 89.00, 0.10, '20241027'),(1002, 2003, '办公椅', '家具', 1, 450.00, 0.00, '20241027'),(1002, 2004, '书桌', '家具', 1, 680.00, 0.15, '20241027'),(1003, 2005, '智能手机', '电子产品', 1, 2999.00, 0.08, '20241027'),(1003, 2006, '手机壳', '配件', 3, 25.00, 0.20, '20241027'),(1004, 2007, '打印机', '办公设备', 1, 1200.00, 0.12, '20241027'),(1004, 2008, '打印纸', '耗材', 5, 25.00, 0.05, '20241027'),(1005, 2009, '投影仪', '电子产品', 1, 3500.00, 0.10, '20241027'),(1005, 2010, '投影幕布', '配件', 1, 300.00, 0.00, '20241027'),(1006, 2011, '空调', '家电', 2, 2800.00, 0.15, '20241026'),(1007, 2012, '冰箱', '家电', 1, 4500.00, 0.20, '20241026');
-- 验证明细数据SELECT order_id, COUNT(*) as detail_count, SUM(quantity * unit_price * (1 - discount)) as expected_amountFROM staging_order_details WHERE batch_date = '20241027'GROUP BY order_id ORDER BY order_id;
-- 执行多表关联的并行插入到 orders 表INSERT /*+ parallel(orders, 4) */ INTO orders (order_id, customer_id, order_date, total_amount)SELECT /*+ parallel(4) */     o.order_id,     o.customer_id,     o.order_date,    SUM(od.quantity * od.unit_price * (1 - od.discount)) as total_amountFROM staging_orders oJOIN staging_order_details od ON o.order_id = od.order_idWHERE o.batch_date = '20241027'GROUP BY o.order_id, o.customer_id, o.order_date;
-- 并行插入订单明细数据INSERT /*+ parallel(order_details, 4) */ INTO order_details (order_id, product_id, product_name, quantity, unit_price)SELECT /*+ parallel(4) */     od.order_id,    od.product_id,    od.product_name,    od.quantity,    od.unit_priceFROM staging_order_details odWHERE od.batch_date = '20241027'  AND EXISTS (SELECT 1 FROM orders o WHERE o.order_id = od.order_id);
-- 验证明细数据插入SELECT o.order_id, o.total_amount as order_total,       SUM(d.quantity * d.unit_price) as detail_total,       COUNT(d.detail_id) as item_countFROM orders oLEFT JOIN order_details d ON o.order_id = d.order_idGROUP BY o.order_id, o.total_amountORDER BY o.order_id;

注意：此示例由于基表数据量太少以及外键约束，就算使用并行插入执行计划也不会使用并行。另外值得注意的是并行虽好，可不要贪杯哦，并行会使用大量的 CPU IO 资源，需要合理配置，否则并行就是灾难。

4.3 常见问题与解决方案

问题 1：并行 DML 未生效

• 排查目标表是否存在触发器
• 检查外键约束是否限制并行
• 检查是否在 CHECK 约束或生成列中使用了非并行安全函数
• 验证并行参数配置是否正确

问题 2：性能提升不明显

• 确认 IO 瓶颈是否消除
• 检查并行度设置是否合理
• 分析执行计划是否生成正确的并行路径

问题 3：资源争用严重

• 调整并行度避免过度并行
• 优化检查点和WAL配置
• 考虑使用资源管理工具限制资源使用

五、总结

金仓数据库并行 DML 技术是国产数据库中我见到的第一款实现并行 DML 的数据库，作为国产数据库的重要突破，不仅在实际性能上展现出了竞争力，更为我国数据库产业的发展注入了新的活力，解决了行业中大数据库量变更的一大痛点。只是可参考的资料目前还比较少，连官方文档中目前我都没有看到相关信息，不过随着技术的不断成熟和生态的完善，国产数据库必将在更多关键业务场景中发挥重要作用。

六、参考链接

https://docs.kingbase.com.cn/cn/KES-V9R2C14/perf/sql-optimization/%E6%89%8B%E5%8A%A8SQL%E4%BC%98%E5%8C%96%E7%A4%BA%E4%BE%8B/%E4%BD%BF%E7%94%A8%E5%B9%B6%E8%A1%8C/
https://mp.weixin.qq.com/s/Faiys2gEkpH6ODmaknTbTA
https://mp.weixin.qq.com/s/NzIJ7ql4XAmGUPR5pGj7Eg

注意：本文使用 KES V009R002C014B0009 版本 8c16g 内存的虚拟机进行测试，基于公开技术文档和实测数据编写，旨在为技术选型和实践提供参考。生产环境具体实施请结合实际情况进行充分测试和验证。

全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~

欢迎关注我的微信公众号【JiekeXu DBA之路】，来一起学习新知识！

—————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
ITPUB：https://blog.itpub.net/69968215
腾讯云：https://cloud.tencent.com/developer/user/5645107
—————————————————————

2025 年公众号 JiekeXu DBA之路历史文章合集

2024 年公众号 JiekeXu DBA之路历史文章合集

2023 年公众号 JiekeXu DBA之路历史文章合集

2022 年公众号 JiekeXu DBA之路历史文章合集

2021 年公众号历史文章合集

https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

如何制作一个Token账本【附完整提示词】

AI编程社区

Linco Bridge 开源：在手机端续接 Codex、Claude Code 、Hermes等本地 AI Agent（架构与实践）

AI编程社区

“循环工程”兴起：AI编程进入“自动驾驶”时代

循环工程将上述循环从“人-AI对话”重构为“AI自主闭环”。其核心范式是：开发者设定目标、约束条件和质量标准 → AI系统自动执行“规划→编码→测试→分析→修正”的迭代 → 仅在关键决策点或异常时请求人工介入。在循环工程中，循环本身是第一类工程对象。开发者不再编写“这段代码做什么”，而是编写“这个Agent循环应该怎么运行、怎么判断成功、怎么处理失败”。循环工程的兴起标志着AI编程从“辅助工具”迈