什么时候该用Savepoint保存点

在数据库事务处理里，Savepoint（保存点） 用来在一个大事务中设置“中间存档点”，方便部分回滚，而不是整段事务全废。

简单来说：当你一个事务里有多步操作，且后面某步可能失败、但你不想前面已成功的步骤白做时，就该用 Savepoint。

一、典型使用场景

1. 一个事务里有多步，且部分可失败

例如：

• 扣库存
• 生成订单
• 发优惠券

如果“发优惠券”失败，但“扣库存 + 生成订单”已经成功，你可以用 Savepoint 只回滚到发券前，而不是整单取消。

BEGIN;
UPDATE inventory SET count = count - 1 WHERE id = 1;
SAVEPOINT sp1;
INSERT INTO orders(...) VALUES(...);
SAVEPOINT sp2;
INSERT INTO coupons(...) VALUES(...); -- 可能失败
-- 如果失败
ROLLBACK TO sp2;
COMMIT;

2. 批量处理，允许单条失败不影响整体

比如导入 1000 条数据：

• 每 100 条一个 Savepoint
• 某条出错，只回滚这一批

BEGIN;
SAVEPOINT batch1;
-- 插入 100 条
-- 若出错
ROLLBACK TO batch1;

3. 复杂业务流程中的“可补偿点”

像：

• 银行转账（先扣 A，再加 B）
• 工作流引擎
• 长事务（不推荐但有时不得不）

Savepoint 可用来标记“走到哪了”。

4. 嵌套逻辑 / 存储过程里

在存储过程或函数中：

• 内部逻辑可能失败
• 但调用方希望保留外部已做操作

BEGIN;
UPDATE account SET balance = balance - 100 WHERE id=1;
SAVEPOINT before_proc;
CALL do_risky_thing();
-- 如果异常
ROLLBACK TO before_proc;

二、不适合用 Savepoint 的情况

❌ 简单 CRUD（一条 INSERT / UPDATE）
→ 直接 COMMIT / ROLLBACK 即可

❌ 长事务本身设计有问题
→ Savepoint 不能解决锁表、性能差的问题

❌ 跨数据库 / 分布式事务
→ Savepoint 通常只在单库有效（分布式要用 Saga / TCC）

三、常见数据库支持情况

• MySQL（InnoDB）：支持
• PostgreSQL：支持
• Oracle：支持
• SQL Server：支持（SAVE TRANSACTION）

四、一句话总结

当你“不想全回滚，只想退一步”的时候，就用 Savepoint。

如果你愿意，我可以给你一个具体业务例子 + 完整 SQL 模板。