Oracle PL/SQL存储过程默认不自动提交，事务由客户端控制；过程内DML执行后需显式COMMIT或由调用方提交，否则变更挂起、行锁不释放、其他会话不可见；AUTONOMOUS_TRANSACTION是唯一可在过程内独立提交的例外。
Oracle PL/SQL存储过程执行后数据没提交，不是“过程写错了”，而是事务控制机制本身就没触发提交——COMMIT 不在过程里，就不会自动提交。
PL/SQL过程默认不自动提交
Oracle 的事务边界由客户端（如 SQL*Plus、PL/SQL Developer、JDBC 连接）控制，不是由存储过程自身决定的。哪怕过程里写了 UPDATE、INSERT，只要没显式调用 COMMIT 或 ROLLBACK，变更就一直挂在当前会话的事务中。
- 过程执行完，只是逻辑走完了，
UPDATE语句生效了，但行锁没释放，其他会话查不到新数据，也改不了同一行 - 如果客户端断开连接且未提交，所有变更会被自动回滚
-
AUTONOMOUS_TRANSACTION是唯一例外：它开启独立事务，需在内部自行COMMIT，否则照样卡住
常见误以为“已提交”的场景
很多开发者在 PL/SQL Developer 里点“执行”按钮跑过程，看到“已完成”就以为数据落地了——其实那只是过程执行成功，不是事务提交成功。
- PL/SQL Developer 默认关闭自动提交（AutoCommit），除非你在工具设置里勾选了 “AutoCommit after each statement”
- SQL*Plus 默认也是手动事务模式，
EXEC my_proc;后必须跟COMMIT; - JDBC 连接默认
autoCommit = false，调用CallableStatement.execute()不等于提交
如何确保数据真正提交
有三种可靠方式，选哪种取决于你的调用上下文：
- 在过程内部加
COMMIT;—— 仅适用于业务逻辑明确要求“执行即固化”的场景；注意：这会让过程失去事务灵活性，无法和外部操作一起回滚 - 在客户端调用后立即执行
COMMIT;—— 最常用，比如：BEGIN my_proc(); END;<br>/<br>COMMIT;
- 用
AUTONOMOUS_TRANSACTION封装关键操作（如日志记录），并在其内部COMMIT;—— 适合审计、通知类旁路操作，不影响主事务
最容易被忽略的是：不同客户端对事务边界的处理差异很大，同一个存储过程，在 PL/SQL Developer 里手动点了 Commit，在 Java 应用里却忘了 connection.commit()，结果就是一半数据可见、一半丢失——事务从来不是“过程的事”，而是“谁调用、谁负责收尾”的事。
