SAVEPOINT 是事务内可回滚标记点，非独立事务；ROLLBACK TO SAVEPOINT 仅撤销该点之后操作，事务仍活跃，而 ROLLBACK（无参数）则全量回滚并结束事务。
什么是 SAVEPOINT 以及它和普通 ROLLBACK 的区别
SAVEPOINT 不是独立事务，而是事务内部的标记点；它让 ROLLBACK TO SAVEPOINT 只撤销该点之后的操作，不影响前面已执行的语句。而 ROLLBACK（无参数）会整个事务回滚——这是关键区别，也是部分回滚唯一可行的方式。
常见错误现象：执行 ROLLBACK TO savepoint_a 后发现表数据没变，或报错 ERROR 1305 (42000): SAVEPOINT savepoint_a does not exist，通常是因为没在事务中定义该保存点，或保存点名拼写不一致（大小写敏感、空格多余）。
- 必须在
BEGIN或START TRANSACTION之后、COMMIT或ROLLBACK之前定义 - 保存点名是标识符，不能加引号，比如
SAVEPOINT sp1✅，SAVEPOINT 'sp1'❌ - 同一个事务内可多次定义同名保存点，后定义会覆盖前一个（MySQL 行为）
如何正确嵌套使用 SAVEPOINT 实现多级回滚
实际业务中常需要“试操作”：比如先插入主记录，再批量插入子记录，某条子记录失败时只回滚子部分，保留主记录。这时就得靠多层 SAVEPOINT。
示例场景：向 orders 插入订单，再向 order_items 插入明细；第二条明细出错时，只撤回明细插入，不丢订单：
START TRANSACTION; INSERT INTO orders (id, customer_id) VALUES (1001, 123); SAVEPOINT order_saved; <p>INSERT INTO order_items (order_id, product_id, qty) VALUES (1001, 456, 2); -- 假设这条失败（如 qty 超限），触发异常 INSERT INTO order_items (order_id, product_id, qty) VALUES (1001, 789, 99999); -- ERROR</p><p>ROLLBACK TO order_saved; -- 此时 order_items 为空，但 orders 中 id=1001 的记录仍存在 COMMIT;
- 每个
SAVEPOINT名需唯一且有意义，避免用sp1、sp2这类模糊命名 -
RELEASE SAVEPOINT sp_name可显式释放，防止意外回滚到已废弃的点；但不释放也不会报错 - 注意存储引擎限制：MyISAM 不支持事务和保存点，必须用 InnoDB
SAVEPOINT 在存储过程和自动提交关闭场景下的行为
在存储过程中调用 SAVEPOINT 时，容易忽略隐式提交的影响。比如在函数里执行了 CREATE TABLE，会强制提交当前事务，导致后续 ROLLBACK TO 失效。
另一个坑是自动提交（autocommit=1）未关闭：此时每条语句都是独立事务，SAVEPOINT 定义后立即失效，ROLLBACK TO 必报错。
- 务必确认会话级
autocommit已关：SET autocommit = 0; - 存储过程中若含 DDL（如
ALTER TABLE）、锁表语句（FLUSH TABLES WITH READ LOCK），会隐式提交，保存点失效 - 客户端断连或连接超时，未
COMMIT的事务会被 MySQL 自动回滚，所有保存点一并消失
为什么有些情况下 ROLLBACK TO SAVEPOINT 看似没生效
最常被忽略的是：MySQL 的保存点机制不跨连接，也不跨事务。一旦 COMMIT 执行，所有保存点立即清除；而 ROLLBACK（全回滚）也会清空全部保存点。
还有种隐蔽情况：某些 ORM（如 Django ORM）默认开启事务，但封装了 savepoint 逻辑，直接写原生 SQL 的 SAVEPOINT 可能被框架事务管理器干扰，表现为保存点“不可见”。
- 用
SELECT @@in_transaction和SELECT @@autocommit实时确认事务状态 - 调试时可在关键位置加
SELECT 'at sp1';配合日志，验证是否真执行到了保存点之后 - 不要依赖保存点做“长期状态暂存”——它只是事务内的临时锚点，生命周期严格受限
