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 插入明细；第二条明细出错时，只撤回明细插入，不丢订单：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

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;</p>

• 每个 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'; 配合日志，验证是否真执行到了保存点之后
• 不要依赖保存点做“长期状态暂存”——它只是事务内的临时锚点，生命周期严格受限