Oracle存储过程事务默认不自动提交，未显式COMMIT时DML仅当前会话可见；退出连接会隐式提交，DDL立即触发隐式提交，循环内频繁COMMIT损害原子性与性能，异常时需显式ROLLBACK，SAVEPOINT支持局部回滚。
Oracle PL/SQL 中的 COMMIT 和 ROLLBACK 不是“用了就完事”的开关，而是直接决定数据是否永久落库、事务是否可回退的关键动作。没理解清楚执行时机和上下文，很容易导致数据意外提交或无法回滚。
PL/SQL 过程里不写 COMMIT 就不会提交？
不一定。关键看客户端连接的自动提交模式（AUTOCOMMIT）和过程执行环境：
- SQL*Plus 默认
AUTOCOMMIT OFF，但退出时会自动提交未提交的更改（不是回滚！），这是最常被忽略的陷阱 - 如果在 PL/SQL 块中没写
COMMIT，而调用它的外部工具（如某些 JDBC 驱动、应用框架）启用了自动提交，那每条 DML 语句仍会被单独提交 - 存储过程中显式写
COMMIT后，该事务段立即结束，后续语句属于新事务 —— 且无法再对已提交部分做ROLLBACK
在 LOOP 里频繁 COMMIT 会导致什么？
性能下降 + 事务原子性丢失，而且容易掩盖逻辑错误：
- 每执行一次
COMMIT，Oracle 就要刷 redo log、释放锁、更新 SCN，10000 次循环里写 10000 次COMMIT，比批量提交慢数倍 - 如果第 5001 条插入失败，前 5000 条已提交，无法整体回滚 —— 这违背“要么全成功、要么全失败”的事务本意
- 更安全的做法是：用
SAVEPOINT分段标记，出错时只回滚到最近保存点，比如：SAVEPOINT sp_batch_1;，然后ROLLBACK TO sp_batch_1;
调用多个存储过程时 COMMIT/ROLLBACK 的作用域
COMMIT 和 ROLLBACK 总是作用于当前会话的整个活动事务，不区分过程边界：
- 过程 A 插入数据后没
COMMIT，调用过程 B，B 里执行COMMIT→ A 和 B 的所有 DML 全部提交 - 过程 A 里写了
COMMIT，接着调用过程 B，B 执行出错并ROLLBACK→ 只能回滚 B 里的操作，A 已提交的部分不可逆 - 如果希望过程 B 独立控制事务，必须用自治事务（
AUTONOMOUS_TRANSACTION），否则它天然共享外层事务上下文
异常处理中 ROLLBACK 容易漏掉的细节
单纯在 EXCEPTION 块里写 ROLLBACK 并不保险：
- 如果异常发生在
COMMIT之后，再ROLLBACK无效 —— 因为事务已经结束 - PL/SQL 中
COMMIT或ROLLBACK会隐式关闭所有打开的游标（包括REF CURSOR），若后续还试图 fetch，会报ORA-1001: invalid cursor - 推荐模式：用
SAVEPOINT在关键操作前设锚点，出错时ROLLBACK TO savepoint_name，避免影响前置已确认逻辑
真正难的不是语法，而是判断“这一组操作到底算不算一个业务单元”——COMMIT 的位置，本质是业务语义的断点，不是技术习惯的停顿。
