因为每次commit都触发lgwr同步刷盘，造成大量串行磁盘i/o等待；应改用forall+bulk collect批量处理并批次提交，而非循环内逐行commit。
因为每次 commit 都会强制 lgwr 同步刷盘，把重做日志写进磁盘，而磁盘 i/o 是串行、高延迟操作——循环里每轮都 commit，等于把一次批量工作的开销拆成几百上千次物理写，性能必然断崖式下跌。
为什么 COMMIT 一进循环就变慢？
不是 COMMIT 语句本身慢，而是它背后触发的同步 I/O 不可避免：
-
LGWR必须将Log Buffer中该事务的所有重做记录（含极小的提交记录）强制落盘，这个过程等待的是log file sync事件 - 单次
log file sync平均耗时约 5–15 ms（取决于存储），10 万行循环提交就是至少 1000 秒纯等待 - 频繁提交还会加剧
enq: TX行锁争用：刚释放的锁马上又被下一轮更新申请，其他会话反复被阻塞 - RAC 环境下更严重：每次
COMMIT还要等LMS把 SCN 同步到所有节点，log file sync等待时间直接翻倍甚至更高
FORALL + BULK COLLECT 怎么替代循环内 COMMIT？
这不是语法糖，而是绕过 PL/SQL 行级上下文切换、让 Oracle 底层批量处理的关键组合：
-
BULK COLLECT INTO一次性拉取结果集，避免逐行FETCH开销 -
FORALL将 DML 操作“打包”交给 SQL 引擎执行，生成的重做日志天然连续、可合并 - 配合批次
COMMIT（如每 1000 行一次），log file sync次数从 N 降到 N/1000，I/O 放大效应消失 - 示例片段：
DECLARE TYPE t_id_tab IS TABLE OF NUMBER; l_ids t_id_tab; BEGIN SELECT id BULK COLLECT INTO l_ids FROM source_table WHERE ...; FORALL i IN 1..l_ids.COUNT UPDATE target_table SET status = 'PROCESSED' WHERE id = l_ids(i); COMMIT; -- 全部更新完才提交一次 END;
哪些场景看似合理、实则仍踩坑？
别被“业务要求强一致性”或“怕出错回滚太多”带偏，这些常见误判反而让问题更糟：
- 用自治事务（
AUTONOMOUS_TRANSACTION）在循环里记日志并COMMIT：自治事务确实不干扰主事务，但它自己仍要走完整log file sync流程，I/O 压力照旧 - 把
COMMIT换成SAVEPOINT：SAVEPOINT不触发 LGWR，但无法释放锁、不保证持久性，根本不是提交的替代方案 - 调大
LOG_BUFFER：只能缓解小量提交，对高频循环无效；且过大可能延长单次log file parallel write时间 - 以为加了索引就能提速：DML 性能瓶颈在重做日志 I/O，不在查询路径；索引反而增加重做量
真正关键的判断点，从来不是“要不要提交”，而是“哪一层负责持久化边界”——应用层控制批次粒度，数据库层专注批量执行。一旦在循环里看到 COMMIT，第一反应不应该是调优 LGWR，而是重构数据处理单位。
