MySQL 事务保存点怎么做局部回滚：SAVEPOINT、锁状态与重试边界

批量处理订单时，第三条记录因为业务校验失败，并不一定意味着前两条也要全部撤销。MySQL 的 SAVEPOINT 可以在一个事务里留下中间位置，遇到可恢复错误时用 ROLLBACK TO SAVEPOINT 退回这一段，保留前面的改动，再决定是修正后继续，还是回滚整笔事务。

先看一个会误判的批处理场景

假设事务先写入批次表，再处理订单明细。明细 A 和 B 合法，明细 C 缺少收货地址。如果直接调用 ROLLBACK，批次记录和 A、B 都会消失；如果不回滚，C 的半成品又可能被提交。

保存点的作用是把“可继续的业务错误”与“必须结束的事务错误”分开。它不提供魔法容错，约束冲突、死锁、连接断开这类错误仍然需要按照应用策略结束或重试。

用 SAVEPOINT 划出局部回滚边界

START TRANSACTION;

INSERT INTO import_batch(batch_id, status) VALUES (9012, 'running');
INSERT INTO order_item(order_id, amount) VALUES (1001, 88.00);

SAVEPOINT item_phase;
INSERT INTO order_item(order_id, amount) VALUES (1002, 36.00);

-- 发现 1002 的业务校验不通过
ROLLBACK TO SAVEPOINT item_phase;
UPDATE import_batch SET status = 'partial' WHERE batch_id = 9012;
COMMIT;

这里最终保留批次 9012 和订单 1001，订单 1002 的插入被撤销。ROLLBACK TO SAVEPOINT 之后事务仍处于活动状态，所以代码还必须明确更新批次状态，不能把“回滚成功”误认为“整个事务已经安全完成”。

回到保存点后，哪些状态还要重新确认

保存点不是事务快照的全部替身。回滚到 p 后，在 p 之后创建的保存点会被释放；如果后续流程还要分段处理，应重新执行 SAVEPOINT item_phase_2。应用内已经缓存的对象、计数器和错误集合不会自动回到数据库状态，也要同步修正。

锁是最容易被忽略的一项。InnoDB 的行锁一般仍归当前事务持有，局部回滚不能拿来“顺便解锁”。如果处理路径在这里停顿，其他会话仍可能看到锁等待。可以在同一连接中检查当前事务，再结合 performance_schema.data_locks 和 data_lock_waits 判断是否存在阻塞。

SELECT OBJECT_NAME, INDEX_NAME, LOCK_TYPE, LOCK_MODE
FROM performance_schema.data_locks
WHERE ENGINE = 'INNODB';

运维处理时如何划分可回滚与不可回滚错误

更建议把错误分成两层，而不是看到异常就统一重试：

• 字段缺失、业务状态不允许等可定位错误：回滚到保存点，记录明细错误，继续下一条。
• 死锁、连接中断、事务已被服务端终止等事务级错误：放弃当前事务，由外层重新读取输入并重试。

重试前先确认幂等键和批次状态。特别是应用收到连接异常时，客户端不知道服务端是否已经写入成功，不能只凭本地异常对象就再次插入。

提交前的四项核对清单

1. 查询批次表，确认 status 与成功、失败明细数量一致。
2. 确认错误明细已带上订单号和原因，避免只写一条笼统日志。
3. 检查当前连接仍是预期事务，并确认没有跨连接调用保存点。
4. 遇到锁等待、死锁或连接错误时，走整笔回滚和幂等重试路径。

如果这是长事务，还应记录开始时间和处理条数。保存点越多不代表越安全，过大的事务仍会带来锁持有时间、undo 记录和恢复成本。

常见问题

ROLLBACK TO SAVEPOINT 会提交前面的数据吗？

不会。它只把事务状态退回到保存点，前面的修改仍未提交，最终仍需 COMMIT 或整笔 ROLLBACK。

回滚到保存点会释放全部行锁吗？

不能这样假设。锁的释放与具体存储引擎和语句有关，不能把局部回滚当作通用解锁方案，现场应查看锁表和等待关系。

保存点可以跨数据库连接使用吗？

不可以。保存点属于创建它的事务和连接，连接池切换连接后再执行回滚语句，通常找不到原保存点。

什么时候应该直接 ROLLBACK？

当错误意味着事务上下文已经不可信，例如死锁、连接中断或关键约束失败时，应结束当前事务，再由应用按幂等规则重新处理。

把保存点当成业务边界，而不是万能补丁

局部回滚最适合短小、可判断、能记录结果的事务片段。它让批处理保留已确认的部分，但不会替应用维护内存状态、释放所有锁，也不会替代幂等设计。把保存点、错误记录、锁检查和最终提交放在同一条可观测链路里，才是真正可恢复的事务流程。