MySQL SAVEPOINT 回滚后哪些锁仍然保留

很多人把 ROLLBACK TO SAVEPOINT 理解成“回到之前的状态，所以锁也回去了”。这个理解不完整：它主要撤销保存点之后的行修改，但当前事务仍然活着，InnoDB 也不会因此自动释放保存点后记录到内存中的行锁。只有提交或不带保存点的完整回滚，才会结束事务并清理这批事务资源。

官方资料：https://dev.mysql.com/doc/refman/8.4/en/savepoint.html

记住一句话：ROLLBACK TO SAVEPOINT 回滚的是数据修改，不等于回滚锁的生命周期。普通行锁可能继续持有；如果是保存点后新插入的行，锁信息随事务 ID 记录在行中，回滚时会通过 undo 释放，这是一个需要单独记住的例外。

ROLLBACK TO SAVEPOINT 到底回滚了什么

SAVEPOINT s1 在当前事务中设置一个命名位置。ROLLBACK TO SAVEPOINT s1 撤销从该位置之后发生的行修改，但不会提交、结束事务；比它更晚创建的保存点会被删除。RELEASE SAVEPOINT s1 只是删除保存点本身，也不提交、不回滚数据。

因此，下面四个动作不能混为一谈：

按索引访问时，锁为什么还在

InnoDB 的行级锁本质上锁的是索引记录。按唯一索引定位一行时，通常关注记录锁；范围扫描在默认的 REPEATABLE READ 下还可能涉及 next-key lock，也就是“索引记录锁 + 前面的间隙锁”。间隙锁的作用是阻止其他事务向索引间隙插入，并不等同于某一行数据。

这就解释了一个常见现象：A 先更新一行，设置保存点，再更新另一行；A 回滚到保存点后，第二次更新的数据恢复了，但 B 仍可能在尝试更新那条记录时等待。不要只看 SELECT 的结果判断锁是否释放，也要看事务是否仍未结束、访问走了哪个索引以及当前隔离级别。

如果使用 READ COMMITTED，间隙锁和不匹配记录的释放规则会与默认隔离级别不同；这不是保存点改变了锁语义，而是隔离级别改变了加锁和释放策略。排查时必须把隔离级别、索引和 SQL 类型一起记录。

用两个会话复现锁的边界

准备一张 InnoDB 表，先确保示例数据存在：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  status VARCHAR(20) NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  KEY idx_status (status)
) ENGINE=InnoDB;

INSERT INTO orders (id, status, amount)
VALUES (101, 'new', 39.90), (102, 'new', 59.90);

会话 A 先修改并回到保存点，再故意保持事务不结束：

START TRANSACTION;
-- 中文注释：第一处修改作为保存点之前的事务操作
UPDATE orders SET amount = amount + 10 WHERE id = 101;
SAVEPOINT s1;
-- 中文注释：第二处修改会被 ROLLBACK TO s1 撤销
UPDATE orders SET amount = amount + 20 WHERE id = 102;
ROLLBACK TO SAVEPOINT s1;
-- 中文注释：这里只回滚数据，事务仍然开放，先不要 COMMIT
SELECT id, amount FROM orders WHERE id IN (101, 102);

此时会话 A 看到 102 的金额恢复，但 A 仍持有事务资源。会话 B 可以执行：

START TRANSACTION;
-- 中文注释：尝试修改会话 A 访问过的记录，观察是否等待
UPDATE orders SET status = 'paid' WHERE id = 102;
-- 中文注释：若语句等待，说明不能用数据已回滚来推断锁已释放

实验结束后，在会话 A 执行 COMMIT 或完整 ROLLBACK，再观察会话 B。生产环境排障还应结合 SHOW ENGINE INNODB STATUS、Performance Schema 的锁等待信息和事务列表，确认等待者、阻塞者、索引名与锁类型。

工程上怎么安排保存点

保存点适合把一个较大的业务事务拆成可恢复的小段，例如批量处理时允许某一组失败后撤销，但它不适合替代事务边界。建议按以下原则使用：

• 把事务尽量缩短，网络请求、人工确认和重试不要夹在持锁事务里。
• 回滚到保存点后，要么继续完成并 COMMIT，要么走完整 ROLLBACK，不要把连接交还连接池后再决定。
• 对范围更新、非唯一索引和默认隔离级别，额外考虑间隙锁造成的插入等待。
• 在异常处理和超时路径里记录事务 ID、SQL、索引、隔离级别与最终结束动作。

常见疑问

回滚到保存点后还能继续执行 SQL 吗？可以。它不会结束当前事务，但更晚创建的保存点已不可用，需要按新的逻辑继续或重新设置保存点。

RELEASE SAVEPOINT 能释放锁吗？不能把它当作解锁命令。它只移除保存点；需要结束事务时使用 COMMIT 或不带保存点的 ROLLBACK。

看到数据恢复，为什么另一个会话还在等？因为数据版本和锁资源是两条不同的生命周期。先确认阻塞事务是否结束，再确认索引访问和隔离级别，最后用锁监控核对具体对象。

总结

ROLLBACK TO SAVEPOINT 的核心价值是局部撤销，不是局部解锁。普通保存点后的行锁不要假设会立即释放；新插入行的锁有 undo 释放例外；间隙锁和 next-key lock 还受索引与隔离级别影响。把保存点当作数据恢复工具，把提交或完整回滚当作事务收尾动作，才能避免“数据看起来没问题、请求却持续阻塞”的错觉。