首先需要明确一个关键要点：Oracle 的 UPDATE 语句默认完全不支持并行执行，即便你添加了 /*+ PARALLEL */ 提示也仍然无效——这是数据库的硬性限制，并非配置参数未正确设置。若要利用并行 DML 实现大批量 SQL UPDATE 的显著性能提升，必须深入理解其行为机制。
从根本上讲，第一道门槛是必须显式启用会话级别的并行 DML 开关。Oracle 的并行 DML 属于会话级显式开关，默认处于关闭状态。如果不执行以下命令，所有 UPDATE 都会被强制串行处理。核心要点如下：
ALTER SESSION ENABLE PARALLEL DML必须在UPDATE语句之前单独执行，不能将其与 SQL 写在同一 PL/SQL 块中却放置在 UPDATE 之后- 该命令仅对当前会话生效，连接池（如 Druid、UCP）每次获取连接后都需要重新执行一次，建议将其封装进连接初始化逻辑中
- 执行后可以通过
SELECT * FROM V$SESSION WHERE SID = SYS_CONTEXT('USERENV', 'SID')查询PDML_STATUS字段，确认其值是否为ENABLED
PARALLEL Hint 写法必须严格匹配目标表别名
控制好会话配置只是第一步，真正的难点在于 Hint 的使用。Hint 被忽略的最常见原因是语法位置错误或对象引用不匹配，Oracle 不会报错，只会静默降级为串行执行。
- Hint 必须紧贴在
UPDATE关键字之后，例如：UPDATE /*+ PARALLEL(t 4) */ t SET ...，不能写成UPDATE t /*+ PARALLEL(t 4) */ SET ... - 如果 UPDATE 子句中使用了别名（如
UPDATE my_table t SET ...），Hint 中必须使用该别名t，而不能用原表名my_table - 若未定义别名，又想使用 PARALLEL 提示，则必须先加上别名：
UPDATE my_table t /*+ PARALLEL(t 4) */ SET ... - 当包含子查询（如
WHERE EXISTS）时，PARALLEL 只作用于主表t，子查询仍以串行方式执行，不要期待整个语句完全并行化
并行度（DOP）设置不当反而引发锁争用
设置 PARALLEL(t 16) 并不代表实际会投入 16 个 PX 进程，过高的 DOP 在 UPDATE 场景下极易触发 enq: TX - row lock contention 或 ORA-12838 错误。
- 实际 DOP 受
CPU_COUNT、PARALLEL_THREADS_PER_CPU、PARALLEL_MAX_SERVERS三者共同限制，可以通过SELECT * FROM V$OSSTAT WHERE STAT_NAME IN ('NUM_CPUS', 'PHYSICAL_MEMORY_BYTES')查看硬件上限 - UPDATE 属于写操作，DOP 过高会导致热点块竞争，尤其当更新主键或索引键连续值时，buffer busy waits 会急剧上升
- 建议初始 DOP 设为
min(4, CPU_COUNT / 2)，然后根据 AWR 报告中gc buffer busy和enq: TX等待事件的值进行调整 - 分区表可以配合
PARTITION子句进一步限定范围，避免跨分区扫描导致的额外开销
并行DML + BULK COLLECT + FORALL 是更稳的组合方案
简单来说，纯 PARALLEL UPDATE 适合全表或大范围条件更新；但如果需要根据关联查询结果更新（例如“用表B更新表A”），将 FORALL 批量处理与并行 DML 结合使用，可控性更强。
- 首先使用
BULK COLLECT INTO将驱动数据（如 ID 和新值）加载到 PL/SQL 集合中，避免逐行游标带来的开销 - 然后通过
FORALL i IN 1..arr.COUNT UPDATE ... WHERE id = arr(i).id批量提交，虽然每个UPDATE本身仍是单条语句，但批量提交减少了上下文切换 - 若该
FORALL块所在的会话已启用PARALLEL DML，且UPDATE语句包含合法的PUBLIC提示，则每条 UPDATE 可能并行执行——但请注意：Oracle 对 FORALL 内部单条语句的并行支持有限，实际测试中更推荐将 FORALL 用于非并行场景，而将 PARALLEL 留给独立的大范围 UPDATE - 要追求极致性能，优先考虑
CREATE TABLE AS SELECT或INSERT /*+ APPEND */重建表，再通过RENAME切换，这比原地 UPDATE 快一个数量级
总体而言，并行 DML 并非打开开关就能直接提速，它实际上将资源争用从 I/O 层面转移到了锁和内存结构上。最容易忽略的一点是：UPDATE 的并行收益高度依赖数据分布——如果 WHERE 条件命中大量相邻数据块，即使 DOP 设置再高，也会卡在 buffer cache 争用上。
