savepoint本身不存数据，大量savepoint不会拖慢回滚；真正影响回滚速度的是事务产生的undo record数量，而非savepoint个数。
Savepoint本身不存数据，但大量Savepoint会拖慢回滚？
不会。MySQL 的 SAVEPOINT 本质只是在事务的 undo log 链上打一个标记指针，不额外写日志、不复制数据、也不占用独立空间。所谓“Savepoint过大导致回滚慢”，实际是误判——真正拖慢回滚的，是它背后那个**已经生成了海量 undo record 的大事务**。你设了 100 个 SAVEPOINT，但只要事务只改了 10 行，回滚到任意点都几乎瞬时；反之，哪怕只设 1 个 SAVEPOINT，事务更新了 50 万行，回滚到它照样卡住。
为什么回滚到 Savepoint 有时仍很慢？
回滚到某个 SAVEPOINT 的耗时，取决于该点之后产生的 undo 记录数量，而非保存点个数。常见真实瓶颈包括：
- 事务中执行了未加
WHERE条件的UPDATE或DELETE，触发全表扫描 + 全表 undo 写入 - 在循环中反复
INSERT却未分批提交，导致 undo log 持续累积（即使中间设了SAVEPOINT a、SAVEPOINT b…） - 事务内混合了 DML 和长耗时逻辑（如调用外部 HTTP、等待用户输入），拉长事务生命周期，间接放大 undo 积压风险
- 使用
SELECT ... FOR UPDATE锁定了大量无关行，虽不写 undo，但回滚时需逐个释放锁，增加上下文清理开销
如何用 Savepoint 实现“可控回滚”而不加重负担
目标不是“减少 Savepoint 数量”，而是让每个 SAVEPOINT 落在**低 undo 增量、短执行窗口**的位置。实操建议如下：
- 只在批量操作的**批次边界**设
SAVEPOINT：例如每处理 1000 行后执行SAVEPOINT batch_123，而不是每插入 1 行就设一个 - 避免在单条宽字段更新语句前后设点：比如
UPDATE t SET json_col = '{...}' WHERE id = 123，若该 JSON 很大，一次更新就产生数 KB undo，此时设点意义不大，应优先压缩字段或拆解逻辑 - 对只读+校验类操作，显式用
START TRANSACTION READ ONLY，彻底绕过 undo 分配——这类事务根本不需要SAVEPOINT - 用
SHOW ENGINE INNODB STATUS\G观察ROLLING BACK状态下的undo n recs值，确认当前回滚压力是否真来自该事务后续段，而非前置段残留
比 Savepoint 更有效的“回滚减速带”方案
当业务需要频繁部分回滚，又担心 undo 累积，可替换为更轻量的控制机制：
- 用临时表暂存中间结果：
CREATE TEMPORARY TABLE tmp_batch AS SELECT ...，出错时直接DROP TEMPORARY TABLE，零 undo 开销 - 应用层维护状态快照：在关键节点将主键 ID 列表或校验和存入内存/Redis，失败时通过
DELETE FROM t WHERE id IN (...)清理，比回滚更可控 - 对导入类任务，改用
LOAD DATA INFILE+DISABLE KEYS，失败时删文件重来，避免事务内堆积 - 必要时启用
innodb_undo_log_truncate=ON并设合理innodb_max_undo_log_size（如 2G），确保小事务提交后 undo 能及时截断，不拖累后续大事务
Savepoint 是工具，不是补丁。真正决定回滚快慢的，永远是那条 UPDATE 语句扫了几行、改了几字节、锁了哪些索引页——盯住这个，比数保存点个数有用得多。
