oracle的update语句默认不走并行，需先执行alter session enable parallel dml，再配合严格语法的parallel hint（如update /+ parallel(t 4) / t set...），且dop设置需结合硬件与等待事件谨慎调优。
Oracle的UPDATE语句默认完全不走并行，哪怕你写了/*+ PARALLEL */提示也无效——这是硬性限制，不是配置没调好。
ALTER SESSION ENABLE PARALLEL DML 必须显式执行
并行DML（PDML）在Oracle中是会话级显式开关，默认关闭。不执行这句，所有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被忽略的最常见原因是语法错位或对象引用错误，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争用上。
