MySQL SAVEPOINT在复杂业务事务中的使用方法

SAVEPOINT 必须在显式事务中使用；当 autocommit=1 时不会生效。ROLLBACK TO SAVEPOINT 不会释放锁；同名保存点会被静默覆盖；DDL 会隐式提交，导致保存点失效。

SAVEPOINT 必须在显式事务中才有效

当 autocommit=1 时，执行 SAVEPOINT sp1 看起来像是成功了，返回结果也会显示 Query OK；但如果继续执行 ROLLBACK TO SAVEPOINT sp1，就会报错：ERROR 1305 (42000): SAVEPOINT sp1 does not exist。这并不是语法问题，而是事务实际上并未开始。

可通过执行 SELECT @@autocommit, @@in_transaction; 确认当前会话状态。只有在事务真正开启后，保存点才有效。仅执行 SET autocommit = 0 并不充分，还需要配合 BEGIN 或 START TRANSACTION。

• 在连接池场景中尤其需要注意：如果上一个请求没有执行 COMMIT 或 ROLLBACK，当前请求直接执行 SAVEPOINT 就可能出现问题，MySQL 会认为事务状态异常
• 部分 ORM（如 SQLAlchemy）默认不会直接暴露 SAVEPOINT；使用 PyMySQL 等原生驱动时，需要确保所有操作都在同一个 Connection 实例中完成

ROLLBACK TO SAVEPOINT 不会释放锁

这是最容易被误解的一点：回滚到保存点之后，虽然表中数据看起来已经恢复，但其他事务仍然可能被阻塞。原因在于 InnoDB 不会释放该保存点之后操作所持有的锁。

例如执行 INSERT INTO t VALUES (1)，再执行 SAVEPOINT sp，随后执行 ROLLBACK TO SAVEPOINT sp，虽然该行数据已经被撤销，但相关的插入意向锁（IX）和隐式锁仍会保留，直到整个事务执行 COMMIT 或完整 ROLLBACK 为止。

• 在执行 SELECT ... FOR UPDATE 之后设置保存点并回滚，锁状态不会发生变化
• 验证锁状态时不能只看数据是否恢复，还应检查 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS
• 不能依靠 ROLLBACK TO SAVEPOINT 解决并发冲突，因为它只能回滚数据，不能回滚锁

同名 SAVEPOINT 会静默覆盖，命名应带上下文

如果连续两次执行 SAVEPOINT loop_step，第二次会直接覆盖第一次，不会报错，也不会有警告。因此，执行 ROLLBACK TO SAVEPOINT loop_step 时，只会回到最后一次设置保存点的位置，而不是预期中的某次循环起点。

保存点名称长度超过 64 个字符时会被截断，且大小写不敏感，例如 SP1 和 sp1 会被视为同一个保存点。命名时建议采用短前缀加业务标识和序号的方式，例如 sp_ord_123、sp_batch_007。

• 在存储过程或循环中写死固定名称，容易导致逻辑断点错位
• RELEASE SAVEPOINT sp_name 是唯一的显式清理方式；即使不执行释放，也不会报错，但后续使用同名保存点时仍会被覆盖
• DDL 语句（如 ALTER TABLE）会触发隐式 COMMIT，从而使所有保存点立即失效，这属于 MySQL 的设计行为

SAVEPOINT 不是子事务，而是 undo log 的偏移标记

从本质上看，SAVEPOINT 只是 InnoDB 在事务结构中记录的一个 undo log 偏移位置，开销较小，但能力有限。它不能只撤销某一条语句，而是只能回滚该保存点之后的所有变更，包括 DML 以及部分 DDL 影响。

一个常见误解是认为它可以单独撤回某一条 UPDATE。实际上，如果没有在该语句之前设置 SAVEPOINT，那么后续只能连同该点之后的所有操作一起回滚。

• 触发器中产生的修改，外层的 ROLLBACK TO SAVEPOINT 无法单独撤销，除非触发器内部自行设置保存点并回滚
• 在 XA 事务模式下，SAVEPOINT 不可使用
• 事务提交或完整回滚后，所有保存点都会自动清除，RELEASE 的作用主要是明确事务控制意图，并非必须执行

SAVEPOINT 的核心作用在于控制回滚边界，而不是提供并发隔离。它适用于“发生错误后保留前面已成功步骤”的场景，而不适用于“让多步操作彼此隔离”的需求。实际使用中，锁行为以及 DDL 的隐式提交尤其需要注意，否则容易引发逻辑错乱、死锁，甚至主从不一致等问题。