为什么Oracle PL/SQL存储过程执行后数据没有提交

Oracle PL/SQL存储过程默认不自动提交，事务由客户端控制；过程内DML执行后需显式COMMIT或由调用方提交，否则变更挂起、行锁不释放、其他会话不可见；AUTONOMOUS_TRANSACTION是唯一可在过程内独立提交的例外。

Oracle PL/SQL存储过程执行后数据没提交，不是“过程写错了”，而是事务控制机制本身就没触发提交——COMMIT 不在过程里，就不会自动提交。

PL/SQL过程默认不自动提交

Oracle 的事务边界由客户端（如 SQL*Plus、PL/SQL Developer、JDBC 连接）控制，不是由存储过程自身决定的。哪怕过程里写了 UPDATE、INSERT，只要没显式调用 COMMIT 或 ROLLBACK，变更就一直挂在当前会话的事务中。

1. 过程执行完，只是逻辑走完了，UPDATE 语句生效了，但行锁没释放，其他会话查不到新数据，也改不了同一行
2. 如果客户端断开连接且未提交，所有变更会被自动回滚
3. AUTONOMOUS_TRANSACTION 是唯一例外：它开启独立事务，需在内部自行 COMMIT，否则照样卡住

常见误以为“已提交”的场景

很多开发者在 PL/SQL Developer 里点“执行”按钮跑过程，看到“已完成”就以为数据落地了——其实那只是过程执行成功，不是事务提交成功。

1. PL/SQL Developer 默认关闭自动提交（AutoCommit），除非你在工具设置里勾选了 “AutoCommit after each statement”
2. SQL*Plus 默认也是手动事务模式，EXEC my_proc; 后必须跟 COMMIT;
3. JDBC 连接默认 autoCommit = false，调用 CallableStatement.execute() 不等于提交

如何确保数据真正提交

有三种可靠方式，选哪种取决于你的调用上下文：

1. 在过程内部加 COMMIT; —— 仅适用于业务逻辑明确要求“执行即固化”的场景；注意：这会让过程失去事务灵活性，无法和外部操作一起回滚
2. 在客户端调用后立即执行 COMMIT; —— 最常用，比如：

   BEGIN my_proc(); END;
   /
   COMMIT;

3. 用 AUTONOMOUS_TRANSACTION 封装关键操作（如日志记录），并在其内部 COMMIT; —— 适合审计、通知类旁路操作，不影响主事务

最容易被忽略的是：不同客户端对事务边界的处理差异很大，同一个存储过程，在 PL/SQL Developer 里手动点了 Commit，在 Java 应用里却忘了 connection.commit()，结果就是一半数据可见、一半丢失——事务从来不是“过程的事”，而是“谁调用、谁负责收尾”的事。