SAVEPOINT必须在活跃事务中定义，依附于事务生命周期；ROLLBACK TO SAVEPOINT后须显式COMMIT，否则全事务不落库；同名保存点会被覆盖，需按业务阶段命名；回滚释放对应行锁但不倒退序列值。
SAVEPOINT必须在事务活跃时定义，不能在已提交或已回滚的事务中使用
Oracle里SAVEPOINT不是独立语句，它依附于当前事务生命周期。如果存储过程中前面有COMMIT或ROLLBACK，再执行SAVEPOINT会报错ORA-01453: SET TRANSACTION must be first statement of transaction（实际错误因上下文而异，但本质是事务状态不合法）。常见踩坑点是：在循环处理前没显式BEGIN，或误以为每次INSERT都自动开启新事务。
正确做法是确保整个存储过程运行在单个事务内——除非业务明确需要分段提交。这意味着：
- 避免在过程体中提前写
COMMIT，除非你清楚知道这是业务语义终点 - 不要依赖隐式事务；Oracle PL/SQL中，事务始于第一条DML，止于
COMMIT/ROLLBACK，中间所有SAVEPOINT都有效 - 如果调用方已开启事务（比如从另一个PL/SQL块调用），子过程直接复用该事务上下文，无需额外
BEGIN
ROLLBACK TO SAVEPOINT后必须显式COMMIT，否则修改仍不落库
这是最常被忽略的环节。ROLLBACK TO SAVEPOINT只撤销保存点之后的变更，事务本身继续运行，且仍处于“未提交”状态。如果你在回滚后没跟COMMIT，整个事务（包括保存点之前的DML）都不会写入数据库——看起来像“白干了”，其实只是卡在缓存里。
典型错误模式：
-
SAVEPOINT sp1;→ 插入A →SAVEPOINT sp2;→ 插入B → 出错 →ROLLBACK TO sp1;→ 忘记COMMIT - 结果：A没入库，B被撤回，整个事务挂起，连接可能被其他会话阻塞
建议在每个ROLLBACK TO分支末尾强制加COMMIT，或统一在过程结尾做一次COMMIT（前提是逻辑允许）。
同名SAVEPOINT会被覆盖，多层嵌套需命名清晰
Oracle不支持同名保存点共存：SAVEPOINT sp1;后再执行一遍SAVEPOINT sp1;，前者即失效。这在循环或递归调用中容易出问题——比如你在for循环里每次都写SAVEPOINT loop_start;，实际只有最后一次生效。
实操建议：
- 用动态命名，比如拼入循环索引：
'sp_' || i（需转为字符串并用EXECUTE IMMEDIATE） - 更稳妥的做法是按业务阶段命名：
SAVEPOINT before_stock_deduct;、SAVEPOINT after_points_added; - 避免在异常处理块中重复定义同一名称，尤其当
EXCEPTION块可能被多次进入时
异常触发ROLLBACK TO后，锁和一致性状态会立即释放对应行
ROLLBACK TO SAVEPOINT不只是数据回退，它还会释放该保存点之后所有DML语句持有的行级锁。这对并发场景很关键：比如你更新了100行并设sp1，之后又更新其中20行并设sp2，再ROLLBACK TO sp1，那20行的锁立刻释放，其他会话可马上修改它们；但前100行的锁仍保留（因为它们在sp1之前）。
这也意味着：
- 不能靠
ROLLBACK TO来“试探性加锁”，因为锁释放是精确到保存点边界的 - 如果保存点之间涉及大量更新，回滚开销不低——Oracle要重放undo日志，性能影响接近一次小事务回滚
- 自增列（如
SEQUENCE.NEXTVAL）即使回滚也不会倒退，这是设计使然，别指望靠ROLLBACK TO恢复ID连续性
SAVEPOINT本身重要得多。 
