MySQL SAVEPOINT 局部回滚怎么用：批量订单处理的事务边界与失败重试

批量导入订单时，最麻烦的不是“事务能不能回滚”，而是某一条记录失败后，到底该不该让整批数据全部作废。MySQL 的 SAVEPOINT 可以把一次大事务切成可控的小边界：保留前面已经通过的订单，回滚当前订单的局部变更，记录失败原因，再决定是否重试或继续处理。

先把整批成功和单条失败分开

假设运营每天导入一批待支付订单，每条订单需要写入订单状态和支付流水。最简单的写法是一个事务包住全部循环：第一条、第二条都成功，第三条失败，最后执行整批回滚。它的好处是数据绝对整齐，代价是一个脏数据或临时冲突就会让前面几十条订单全部白做。

另一种极端是每条订单单独提交。这样一条失败不会影响其他订单，但批次中间如果进程退出，已经提交的订单和未处理的订单就需要额外的批次状态来管理。SAVEPOINT 适合夹在两者之间：外层仍是一笔批次事务，内层每条订单有自己的回滚点。

用一组最小 SQL 看清 SAVEPOINT 的作用

先准备两张足够小的测试表。真实项目中可以替换成现有的 orders 和 payment_records，但不要直接在生产表上做这组实验。

CREATE TABLE batch_orders (
  id BIGINT PRIMARY KEY,
  status VARCHAR(20) NOT NULL,
  amount DECIMAL(10, 2) NOT NULL
) ENGINE=InnoDB;

CREATE TABLE batch_payments (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  order_id BIGINT NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  UNIQUE KEY uk_payment_order (order_id)
) ENGINE=InnoDB;

INSERT INTO batch_orders (id, status, amount) VALUES
(1001, 'pending', 39.90),
(1002, 'pending', 59.00),
(1003, 'pending', 88.80);

然后模拟一批订单。第二条订单故意写入重复的支付流水，触发唯一键冲突；我们希望 1001 保留成功状态，1002 回滚自己的写入，1003 继续处理。

START TRANSACTION;

SAVEPOINT order_1001;
UPDATE batch_orders SET status = 'paid' WHERE id = 1001;
INSERT INTO batch_payments (order_id, amount) VALUES (1001, 39.90);

SAVEPOINT order_1002;
UPDATE batch_orders SET status = 'paid' WHERE id = 1002;
INSERT INTO batch_payments (order_id, amount) VALUES (1002, 59.00);
-- 如果这里出现异常：ROLLBACK TO SAVEPOINT order_1002;

SAVEPOINT order_1003;
UPDATE batch_orders SET status = 'paid' WHERE id = 1003;
INSERT INTO batch_payments (order_id, amount) VALUES (1003, 88.80);

COMMIT;

注意一个容易忽略的事实：ROLLBACK TO SAVEPOINT 只撤销回滚点之后的修改，不会结束事务。回滚后可以继续执行下一条订单；但如果调用了 ROLLBACK，整个批次都会结束，前面已经成功的订单也会被撤销。

把异常边界写成可检查的批处理流程

生产代码不要把每条订单的所有异常都当成“回滚后继续”。建议先给失败分级，再决定动作。唯一键冲突、格式不合法通常可以记录后跳过；余额不足、订单金额被篡改或关键账户状态异常，则可能需要终止整批。

这里的重点是让“继续”和“终止”成为显式业务决策，而不是被异常处理结构偶然决定。批次表最好保存 total_count、success_count、failure_count 和 status，这样提交后的结果能被再次核对。

每条订单的回滚点应该怎样命名和清理

保存点名称只在当前连接的当前事务里有意义。循环中可以使用固定名称，例如 order_item，每次新建时覆盖同名保存点；也可以使用带订单号的名称，排查日志时更直观。无论采用哪种方式，都要防止把用户输入直接拼接到 SQL 中，保存点名称应由程序生成并限制为安全字符。

START TRANSACTION;
SAVEPOINT order_item;

-- 当前订单的所有写入
UPDATE batch_orders
SET status = 'paid'
WHERE id = 1001 AND status = 'pending';

-- 发生可恢复异常时
ROLLBACK TO SAVEPOINT order_item;

-- 完成后释放不再需要的保存点
RELEASE SAVEPOINT order_item;
COMMIT;

RELEASE SAVEPOINT 会释放保存点，但不会提交事务。事务提交或整笔回滚后，所有保存点也都会失效。循环量很大时，及时释放已经完成的保存点可以减少事务状态占用，不过更重要的是控制整批事务的总时长，避免长时间持有行锁。

哪些情况不适合继续使用局部回滚

局部回滚并不是“批量处理万能胶”。如果前一条订单已经发送了外部通知、扣了第三方余额或写入了不能撤销的文件，那么数据库局部回滚无法把这些外部动作一起撤销。此时要么把外部动作放到数据库提交之后，并用可靠消息补偿；要么改成每条订单独立事务，再用批次状态跟踪进度。

还要留意存储引擎。只有支持事务的表才能提供这里讨论的事务语义，实验表使用 InnoDB 正是这个原因。跨连接创建的保存点也互不认识；连接池场景中，创建保存点、处理写入和回滚必须在同一条数据库连接上完成。

上线前用四个检查点确认结果

1. 事务连接：确认保存点和局部回滚使用的是同一连接，没有被连接池切换。
2. 异常分级：明确哪些错误可以跳过，哪些错误必须终止整个批次。
3. 结果核对：提交前后对比成功、失败、跳过和重试数量，保证总数守恒。
4. 长事务告警：观察事务持续时间、锁等待和批次大小，超过阈值就拆小批次。

如果局部回滚后的订单仍显示为 paid，先别急着怀疑 MySQL。优先检查更新语句是否在保存点之前执行、异常后是否真的调用了 ROLLBACK TO SAVEPOINT，以及后续代码有没有再次写回成功状态。

常见问题

SAVEPOINT 回滚后还能继续执行 SQL 吗？

可以。局部回滚不会结束外层事务，后续 SQL 仍可执行；只有整笔 ROLLBACK 或连接异常才会结束当前事务。

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

不能。保存点绑定创建它的连接和事务，连接池代码必须保证同一条连接完成创建、写入、回滚与提交。

每条订单都建立保存点会不会让事务变慢？

会增加事务管理开销，但通常比整批失败后全部重做更可控。真正需要关注的是批次大小、事务持续时间、锁等待和保存点释放策略。

遇到所有异常都应该局部回滚吗？

不应该。可跳过的脏数据可以局部回滚后记录；数据一致性、权限或关键账户异常则应终止批次，并交给人工或补偿流程处理。

最后的复盘清单

设计 MySQL 批量事务时，可以把判断压缩成一句话：外层事务负责批次边界，保存点负责单条订单边界，批次状态负责事后核对。上线后继续关注批次耗时、成功率、失败原因分布和重试结果；如果失败记录持续增长，应该修数据源或业务校验，而不是无限增加重试次数。