SAVEPOINT支持局部回滚，是大批量更新中实现可控回滚的关键机制；它在当前事务内设标记点，可用ROLLBACK TO SAVEPOINT回退至该点，不影响此前操作，需配合分批处理与索引优化使用。
大批量更新事务一旦失败，全量回滚代价高、耗时长、还可能锁表卡住其他业务。真正的故障安全不是“全回滚”，而是“可控回滚”——用保存点（SAVEPOINT）切分操作单元，让失败只影响局部，主流程仍可提交。
SAVEPOINT 是唯一能实现部分回滚的 SQL 原生命令
MySQL/PostgreSQL/SQL Server 都支持 SAVEPOINT，但 Oracle 和早期 SQLite 版本不支持（需用自治事务替代）。它不是事务嵌套，也不创建新事务上下文，只是在当前事务内打一个标记点，后续可用 ROLLBACK TO SAVEPOINT 回退到该点，不影响此前已执行的语句。
- 必须在
BEGIN TRANSACTION或START TRANSACTION之后定义，不能在自动提交模式下使用 - 每个
SAVEPOINT名称在当前事务中必须唯一；重复定义同名会覆盖前一个 -
RELEASE SAVEPOINT可显式释放（非必需），但事务提交或回滚后所有保存点自动失效
分批次 + 保存点是大批量更新的黄金组合
直接对百万行执行 UPDATE ... WHERE id BETWEEN 1 AND 1000000 是高危操作：单语句锁行过多、undo log 爆涨、超时风险陡增。正确做法是按主键分页 + 每批设保存点：
START TRANSACTION; UPDATE orders SET status = 'shipped' WHERE id BETWEEN 1 AND 1000; SAVEPOINT batch_1; <p>UPDATE orders SET status = 'shipped' WHERE id BETWEEN 1001 AND 2000; SAVEPOINT batch_2;</p><p>-- 若 batch_2 出错（如触发器抛异常），可： ROLLBACK TO SAVEPOINT batch_1; -- 继续尝试修复后重试 batch_2，或跳过该批 COMMIT;
- 每批控制在 500–5000 行，具体取决于单行数据大小和索引效率
- 务必确保
WHERE条件走索引，否则UPDATE会升级为表锁，保存点也救不了阻塞 - 不要在循环里无条件
SAVEPOINT（如SAVEPOINT sp_i），容易因命名冲突或内存累积出错
应用层调用时必须捕获底层错误并主动回滚到保存点
ORM（如 SQLAlchemy、Laravel Eloquent）默认不暴露保存点接口，需绕过封装直连原生连接执行 SAVEPOINT 和 ROLLBACK TO SAVEPOINT。例如在 Flask-SQLAlchemy 中：
from flask_sqlalchemy import SQLAlchemy
db = SQLAlchemy()
<p>with db.engine.connect() as conn:
trans = conn.begin()
try:
conn.execute("SAVEPOINT before_batch_1")
conn.execute("UPDATE users SET email = %s WHERE id = %s", ("a@b.com", 123))</p><pre class='brush:php;toolbar:false;'> conn.execute("SAVEPOINT before_batch_2")
conn.execute("UPDATE orders SET total = total * 1.1 WHERE user_id = %s", (123,))
# 若此处报 IntegrityError，下面回滚只影响 orders 更新
trans.rollback_to_savepoint("before_batch_2")
trans.commit()
except Exception as e:
trans.rollback()
raise- ORM 的
session.rollback()是全局回滚，无法替代ROLLBACK TO SAVEPOINT - Python 的
psycopg2、PHP 的PDO、Java 的JDBC都需通过Connection对象执行保存点命令，不能依赖事务装饰器 - 若用连接池（如 HikariCP），要确认连接未被归还——保存点只在当前连接生命周期内有效
哪些情况会让 SAVEPOINT 失效或变危险？
保存点不是银弹。以下场景下它要么不起作用，要么引发更严重问题：
- DDL 操作（如
ALTER TABLE）在多数数据库中会隐式提交当前事务，所有保存点立即丢失 - 跨库或跨表 JOIN 更新时，若涉及无索引字段，InnoDB 可能升级为间隙锁甚至表锁，保存点只能回退语句，但锁已持有
- MySQL 5.7+ 在 RR 隔离级别下，
SELECT ... FOR UPDATE后的保存点，若后续 UPDATE 触发死锁，回滚到保存点可能仍留有锁等待 - 长时间运行的批量任务中，未设置
innodb_lock_wait_timeout，会导致ROLLBACK TO SAVEPOINT等待超时而非立即生效
真正难的不是加保存点，而是在业务逻辑分层中识别「可降级操作」——比如发通知、写日志、更新统计缓存这些非核心步骤，应该从主事务中剥离，而不是靠保存点硬扛。保存点解决的是“已进事务的不可逆操作如何局部止损”，不是“该不该把这步放进来”的架构问题。
