MySQL 事务中使用 SAVEPOINT 后怎样只回滚部分写入

如果一笔订单事务里，基础订单必须保留，但可选的积分、日志或附加明细失败后只想撤销这一段，可以使用 SAVEPOINT。它不是另开一笔事务，而是在当前事务中留下一个命名回退点；ROLLBACK TO SAVEPOINT 只撤销保存点之后的修改，事务仍然可以继续，最后再由 COMMIT 一次性提交。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/savepoint.html

本文只讨论 InnoDB 的单连接事务边界，不延伸到分布式事务、ORM 自动事务或跨库补偿。

先明确 SAVEPOINT 到底回滚哪一段

可以把事务想成一张还没有提交的草稿：保存点记录的是“当前草稿位置”，而不是数据库已经落盘的提交点。保存点前的写入仍属于当前事务，保存点后的写入才是局部回滚的候选。

因此，ROLLBACK TO SAVEPOINT sp_optional 不等于 ROLLBACK：前者保留事务，让后续 SQL 仍可执行；后者会撤销整笔事务。MySQL 8.4 手册还说明，回滚到保存点后，比该保存点更晚创建的保存点会被删除。

用一个最小 SQL 场景建立保存点

下面的例子把订单主记录视为必要写入，把可选的积分流水放在保存点之后。代码是可复制的示例，运行前请准备 InnoDB 表，并把示例订单号替换成业务数据。

-- 开启同一连接上的事务，后续写入先不提交
START TRANSACTION;

-- 必要写入：订单主记录应当和最终提交绑定
INSERT INTO orders(order_no, status) VALUES ('A20261113001', 'created');

-- 保存“必要写入已经完成”的局部边界
SAVEPOINT sp_optional;

-- 可选写入：这段失败时只回滚它，不撤销订单主记录
INSERT INTO order_points(order_no, points) VALUES ('A20261113001', 10);

-- 业务决定放弃积分，但继续保留当前事务
ROLLBACK TO SAVEPOINT sp_optional;

-- 回滚后仍可继续修改必要数据
UPDATE orders SET status = 'created_without_points'
WHERE order_no = 'A20261113001';

-- 可选：不再需要这个保存点时释放名称
RELEASE SAVEPOINT sp_optional;

-- 只在所有最终状态确认后提交整笔事务
COMMIT;

预期的结果关系是：订单主记录保留，积分流水被撤销，订单状态更新后随整笔事务提交。这里的“预期”是由 SQL 语义推导出的检查目标，不是本文在本机执行得到的截图或运行证据。

回滚后怎样继续当前事务

关键点是不要在 ROLLBACK TO SAVEPOINT 后立刻执行普通 ROLLBACK。局部回滚完成后，可以继续执行更新、插入或重新设置同名保存点，最后统一 COMMIT。如果应用代码把局部异常直接升级成整笔回滚，就失去了保存点的意义。

工程上可以把保存点放在“可选副作用”前面，把是否回滚的判断留在同一个事务控制层。这样既能保留主业务写入，也能让失败的附加动作不污染最终状态。

最容易踩到的四个边界

• 保存点名称被覆盖：同一事务再次使用相同名称时，旧保存点会被新的位置替换，名称应体现业务阶段。
• 保存点已经不存在：提交、整笔回滚或回滚到更早保存点后，目标名称可能已被清除；此时会得到 ERROR 1305。
• 释放不等于提交：RELEASE SAVEPOINT 只移除保存点，不执行 commit 或 rollback。
• 连接不能混用：保存点属于当前事务和当前连接，连接池切换连接后不能假定保存点还在。

排查时先确认事务是否仍在同一连接上，再按“保存点创建位置 → 局部回滚位置 → 是否发生隐式提交 → 最终 COMMIT”顺序记录日志。对于包含 DDL 的流程，还要单独确认其隐式提交行为，不能把所有语句都当成可局部回滚。

相关问题

问：ROLLBACK TO SAVEPOINT 后事务结束了吗？
答：没有。它只撤销保存点之后的修改，当前事务仍可继续执行，最终仍需显式 COMMIT 或整笔 ROLLBACK。

问：什么时候应该使用 RELEASE SAVEPOINT？
答：当这个局部回退点已经不再需要时可以释放它；即使不释放，执行 COMMIT 或整笔 ROLLBACK 时当前事务的保存点也会被清除。

问：SAVEPOINT 能替代分布式事务吗？
答：不能。它只管理同一数据库事务、同一连接内的局部回滚边界，不能协调多个数据库或外部服务。