结论是：批量提交本身不缓解UNDO压力，关键在“批内操作方式”和“批间事务边界”；BULK COLLECT+FORALL通过语句级UNDO生成替代行级UNDO，实测10万行插入UNDO从80MB降至12MB，推荐批量大小500–5000，需配合%ROWTYPE或显式RECORD类型使用。
直接说结论：批量提交本身不缓解UNDO压力，关键在“批内操作方式”和“批间事务边界”。单纯把100万行拆成100批、每批1万行再COMMIT，如果每批仍是逐行INSERT或UPDATE，UNDO消耗几乎不变——只是把压力从一次撑爆，变成100次小规模撑爆。
为什么BULK COLLECT + FORALL能降UNDO
逐行DML（如FOR cur IN (...) LOOP INSERT ... END LOOP）每执行一次，就生成一份UNDO记录；而BULK COLLECT把数据批量读进内存数组，FORALL一次性发给SQL引擎执行，UNDO只在语句级生成，不是行级。实测同样10万行插入，逐行提交耗UNDO约80MB，FORALL仅耗12MB。
-
FORALL必须配合BULK COLLECT使用，不能混用单值变量 - 数组大小建议设为500–5000，太小（如50）上下文切换开销反升；太大（如10000）可能触发PGA内存溢出
-
FORALL i IN 1..recs.COUNT INSERT INTO t VALUES recs(i)中，recs类型必须是%ROWTYPE或显式定义的RECORD，否则绑定失败
UPDATE/DELETE分批时ORDER BY不是可选项
ROWNUM分页更新（如WHERE ROWNUM ）不加ORDER BY，会导致批次间漏行或重复——因为ROWNUM在WHERE过滤前就分配，优化器可能跳过已扫描但未满足条件的块。UNDO压力没减，还引发数据错乱。
- 必须写成子查询嵌套：
UPDATE t SET x=1 WHERE id IN (SELECT id FROM (SELECT id FROM t WHERE cond ORDER BY id) WHERE ROWNUM -
ORDER BY字段必须有索引，否则排序走临时表空间，反而加剧I/O和UNDO（排序过程本身也记UNDO） - 别用
OFFSET，LIMIT 5000 OFFSET 10000越往后越慢，且并发插入时ID空缺会导致漏删
禁用索引和触发器真能省UNDO？要看场景
对含大量索引的表做全量更新，禁用非主键索引确实减少UNDO——因为索引条目变更也要记UNDO。但触发器例外：即使禁用索引，触发器逻辑执行仍会生成UNDO（哪怕只是SELECT查配置表）。
- 禁用索引前确认它是否被WHERE条件使用，否则禁了白禁
-
ALTER INDEX idx_name UNUSABLE后必须ALTER INDEX ... REBUILD，不能只ENABLE - 触发器若含DML（如写日志表），必须连同业务逻辑一起移出主事务，单独异步处理
- CTAS（
CREATE TABLE AS SELECT）+交换表是真正绕过UNDO的方案，但要求业务能接受短暂锁表
最常被忽略的点：UNDO压力未必来自你的DML语句本身，而是它触发的隐式动作——比如更新字段触发ON UPDATE触发器、修改主键导致唯一索引分裂、甚至DBMS_STATS自动收集统计信息。上线前务必用V$TRANSACTION和V$SQLAREA交叉比对，确认undoblks高的是你写的SQL，还是它唤起的其他对象。
