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;，两个值都必须是 1 和 1 才算真正进入事务。仅 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，所有保存点瞬间失效——这不是 bug，是设计使然
SAVEPOINT 不是子事务，只是 undo log 偏移标记
它本质是 InnoDB 在事务结构体里记的一个 undo log 偏移位置，开销极小，但功能有限：不能选择性撤销某条语句，只能丢弃该点之后所有变更（包括 DML 和部分 DDL）。
常见误解是以为可以“撤回某一条 UPDATE”，实际做不到——只要没在它之前设 SAVEPOINT，就只能连带回滚后续所有操作。
- 触发器内发生的修改无法被外层
ROLLBACK TO SAVEPOINT撤销（除非触发器自己设点并回滚） - XA 事务模式下
SAVEPOINT不可用 - 事务提交或全量回滚时，所有保存点自动清除，
RELEASE是为了明确意图，不是必须动作
