频繁commit让存储过程变慢，因其强制lgwr刷盘、更新undo、释放锁、刷新scn并通知会话，全套动作无法合并；高并发下引发latch争用和log file sync等待飙升，awr中占比超20%即需优化，应结合负载、buffer cache与事务原子性设定合理批量提交。
频繁 COMMIT 为什么让存储过程变慢？
每次 COMMIT 都不是“确认一下就完事”，它强制 LGWR 把 redo buffer 写入磁盘、更新 undo 状态、释放行锁、刷新 SCN、通知其他会话——这些动作无法合并，也不能跳过。哪怕只插 1 行就 COMMIT，全套流程照走。高并发下还会争抢 redo allocation latch 和 redo writing latch，log file sync 等待飙升，AWR 里占比超过 20% 就该怀疑了。
怎么设批量提交才合理？
别硬套“每 10000 行”，得看实际负载和配置：
-
MOD(i, 1000)是安全起点，先试；观察 AWR 中log file sync平均等待是否下降超 50% -
UNDO_RETENTION必须撑住最长事务运行时间，否则中途可能报ORA-01555 - 别跨业务原子性切分：比如“每 10000 条订单”可以，但“每 10000 条订单+其明细”必须用
SAVEPOINT或整体提交 - 如果
DB_BUFFER_CACHE很小（比如低于 2GB），LIMIT 值要往下调，避免 PGA 撑爆
哪些 COMMIT 容易被忽略？
DDL 和自治事务里的 COMMIT 不会报错，但会悄悄破坏主事务一致性：
-
CREATE INDEX、ANALYZE TABLE这类 DDL 语句自带隐式COMMIT，混在循环里等于每轮都提交 - 标记了
PRAGMA AUTONOMOUS_TRANSACTION的子过程，里面调了COMMIT，主过程后续再出错也回滚不了它 -
DBMS_SCHEDULER作业默认提交，若从存储过程中调用，也可能打断主事务流
BULK COLLECT + LIMIT 提交时的实操细节
光写 BULK COLLECT 不够，容易踩内存或逻辑坑：
-
LIMIT推荐值是 100～500，19c 实测 500 在多数 OLTP 场景下最稳；超过 1000 易触发ORA-04030 - 必须配
FORALL，否则只是“伪批量”，上下文切换开销没降 - 退出循环不能只靠
%NOTFOUND，得检查v_batch.COUNT = 0 - 每批处理完要计数提交，例如
IF i MOD 1000 = 0 THEN COMMIT; END IF;，别无条件COMMIT
真正卡点不在怎么写 COMMIT，而在事务边界是否清晰——业务上哪部分必须一起成功或一起失败，决定了你根本不能只看行数切分。
