MySQL Savepoint 仅在显式事务中生效，AUTOCOMMIT=1 时每个语句自动提交，SAVEPOINT 无事务上下文而失效；需先 SET AUTOCOMMIT=0 并用 BEGIN 开启事务。
MySQL Savepoint 为什么不能在 AUTOCOMMIT=1 时生效
Savepoint 只在显式事务中起作用，而 AUTOCOMMIT=1 下每个语句都是独立事务，SAVEPOINT 会被立即提交或忽略。你执行 SAVEPOINT sp1 后紧接着 INSERT，再 ROLLBACK TO sp1，结果却是整个语句回滚失败——因为事务早已结束。
必须先关闭自动提交：SET AUTOCOMMIT = 0，再用 BEGIN 或 START TRANSACTION 显式开启事务，后续的 SAVEPOINT 才有上下文可依附。
- 检查当前模式：
SELECT @@autocommit，值为1就得先关 - 连接池（如 Spring 的 HikariCP）可能默认开启 autocommit，需在数据源配置里显式设
autocommit=false - 某些 ORM（如 Django）在
atomic块内自动管理事务，但手动调用savepoint()仍依赖底层连接处于事务中
SAVEPOINT 名称重复会导致 SQL 错误
MySQL 不允许同名 savepoint 在同一事务中重复定义，否则报错：ERROR 1305 (42000): SAVEPOINT sp1 does not exist——注意这个错误提示其实有误导性，真实原因是前一个 sp1 已被覆盖或释放，而非“不存在”。
根本原因：再次执行 SAVEPOINT sp1 会**隐式释放旧的 sp1 并新建同名点**，但若中间已执行过 RELEASE SAVEPOINT sp1 或 ROLLBACK TO sp1，再定义就会出错。
- 命名建议用带上下文的短字符串，比如
SAVEPOINT sp_user_insert、SAVEPOINT sp_order_update - 避免硬编码字符串，尤其在循环或递归逻辑中；可用变量拼接，如
CONCAT('sp_step_', @i) - 调试时查当前 savepoint 状态？MySQL 没有系统表暴露 savepoint 列表，只能靠代码逻辑保证生命周期清晰
ROLLBACK TO SAVEPOINT 后，后续 INSERT 还能提交吗
可以，而且这是 savepoint 的核心价值：局部回滚不影响事务整体活性。执行 ROLLBACK TO sp1 只撤销从 sp1 到该语句之间的变更，事务仍处于打开状态，后续 INSERT/UPDATE 都有效，最终仍可 COMMIT。
但要注意两个隐形约束：
- 被回滚的语句若涉及自增主键（
AUTO_INCREMENT），ID 已消耗，不会回收——ROLLBACK TO不重置自增计数器 - 如果回滚后又执行了 DDL（如
ALTER TABLE），MySQL 会**强制提交当前事务**，导致所有未提交变更落地，且 savepoint 全部失效 - 存储函数/触发器内使用 savepoint 是允许的，但外层事务
ROLLBACK会连带清除所有内层 savepoint
示例场景：批量导入用户，每 10 条设一个 savepoint；某条因唯一键冲突失败，ROLLBACK TO sp_batch_10，跳过该条继续下一批——只要不退出事务，就能持续推进。
嵌套事务与 Savepoint 的常见误解
MySQL 不支持真正嵌套事务（即 BEGIN 套 BEGIN），所谓“嵌套”只是 savepoint 的模拟。执行 SAVEPOINT sp_a → SAVEPOINT sp_b → ROLLBACK TO sp_a，sp_b 自动失效，但不会报错。
这种线性覆盖模型简单，但也带来易错点：
-
RELEASE SAVEPOINT sp_x只是释放该点，不影响其他 savepoint，但释放后再ROLLBACK TO sp_x就会报错 - 事务中大量无序定义/释放 savepoint 容易失控，建议按业务阶段分组，例如统一用
sp_phase1_start/sp_phase1_end - PHP 的
PDO::beginTransaction()不等价于START TRANSACTION，它只是设置内部标志；真正发往 MySQL 的仍是显式 SQL，所以 PDO 中仍需手写SAVEPOINT语句
复杂业务流程里，savepoint 不是银弹——它无法跨连接、不解决幻读、也不能替代应用层幂等设计。真正容易被忽略的是：一旦连接异常中断，整个事务（含所有 savepoint）都会被服务端自动回滚，没有任何残留状态可恢复。
