主流数据库不支持真正的嵌套事务，但可通过savepoint实现逻辑分段控制与局部回滚；savepoint是事务内标记点，支持rollback to和release操作，适用于局部失败容错等场景。
sql 事务嵌套本身并不存在真正的“嵌套事务”，主流数据库（如 postgresql、SQL Server、mysql InnoDB）只支持单层事务，但可通过 Savepoint 实现逻辑上的分段控制与局部回滚，这是优化复杂业务流程的关键手段。
Savepoint 是什么？它不是嵌套事务
Savepoint 是事务内部的一个标记点，允许在不终止整个事务的前提下回滚到该点。它不创建新事务，也不改变事务的 ACID 属性——整个外层事务仍需显式 COMMIT 或 ROLLBACK 才会生效或撤销。
- 一个事务中可定义多个 Savepoint，名称需唯一（部分数据库允许重名，但建议避免）
- 回滚到 Savepoint（
ROLLBACK TO SAVEPOINT sp_name）只撤销其后执行的语句，不影响之前操作 - 释放 Savepoint（
RELEASE SAVEPOINT sp_name）仅删除标记，不触发任何数据变更
典型适用场景：局部失败不影响主流程
当业务需按步骤执行多个关联操作，但某一步失败时只需撤回该步而非全部重来，Savepoint 就非常实用。
- 订单创建 + 库存扣减 + 积分更新：若积分服务临时不可用，可回滚积分部分，保留订单和库存变更，稍后异步补发
- 批量导入中的单条容错：处理 1000 条记录时，第 502 条违反约束，用 Savepoint 隔离每条，跳过错误继续执行其余
- 条件分支逻辑：根据参数决定是否插入日志表或通知表，任一分支出错不影响其他分支提交
使用 Savepoint 的关键注意事项
看似简单，但误用易引发数据不一致或性能问题。
- Savepoint 不解决死锁或长事务阻塞：它只是回滚逻辑位置，不能替代合理的事务粒度设计；长时间持有事务仍会锁表/行
- 注意数据库兼容性：MySQL 8.0+、PostgreSQL、SQL Server 全支持；sqlite 支持但语法略有差异；oracle 使用
SAVEPOINT但对自治事务（AUTONOMOUS_TRANSACTION）有特殊机制，不属于标准 Savepoint 范畴 - 避免过度嵌套 Savepoint 名称：不用动态拼接名字（如
sp_step_1_20240520），推荐静态命名（sp_order_insert、sp_stock_deduct），便于日志追踪与调试 - 应用层需配合异常捕获：例如在 JDBC 中调用
connection.rollback(savepoint)前，必须确保未发生连接中断或事务已提交
实战写法示例（PostgreSQL）
以下是一个带 Savepoint 的安全转账片段：
BEGIN;
INSERT INTO accounts (id, balance) VALUES (1, 1000);
SAVEPOINT sp_transfer_start;
UPDATE accounts SET balance = balance – 200 WHERE id = 1;
UPDATE accounts SET balance = balance + 200 WHERE id = 2;
— 模拟风控检查失败
— 若此处抛异常，只回滚转账部分
ROLLBACK TO SAVEPOINT sp_transfer_start;
— 补充记录审计日志（仍属于同一事务）
INSERT INTO audit_log (action, status) VALUES (‘transfer’, ‘failed’);
COMMIT;