MySQL存储过程中设SAVEPOINT必须先显式执行BEGIN或START TRANSACTION开启事务，仅SET autocommit=0无效；否则报错“SAVEPOINT does not exist”。
存储过程里设 SAVEPOINT 必须显式 BEGIN TRANSACTION
MySQL 存储过程中，SAVEPOINT 不会自动开启事务。即使你在过程开头写了 SET autocommit = 0，也不等于事务已启动——它只是关闭了自动提交模式，但当前会话仍处于“无事务状态”。直接执行 SAVEPOINT sp1 会报错：(1305, 'SAVEPOINT sp1 does not exist') 或静默失败（取决于客户端行为）。
必须用 BEGIN 或 START TRANSACTION 显式开启事务块，再设保存点：
CREATE PROCEDURE proc_order_insert()
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK TO sp_after_header;
RESIGNAL;
END;
<p>START TRANSACTION; -- 关键：必须有这句
INSERT INTO orders (order_no) VALUES ('ORD-001');
SAVEPOINT sp_after_header; -- 此时才有效
INSERT INTO order_items (...) VALUES (...);
END-
DECLARE EXIT HANDLER中的ROLLBACK TO只能在事务活跃时生效，否则触发Invalid transaction state - 不要依赖存储过程外层调用者开启事务——除非你明确约定“调用方必须传入活跃事务”，否则过程内部必须自包含
- SQL Server 的
SAVE TRANSACTION同理，SAVE TRANSACTION sp1前必须有未配对的BEGIN TRANSACTION
同名 SAVEPOINT 在嵌套逻辑中会被静默覆盖
同一个事务内重复使用相同名字的 SAVEPOINT，MySQL 和 SQL Server 都不会报错，而是直接覆盖前一个。这意味着你写两次 SAVEPOINT sp1，第二次之后再 ROLLBACK TO sp1，只会回到第二次设点的位置，第一次的 undo 状态已丢失。
在存储过程中尤其危险：比如循环插入多条记录，每次都在循环体开头写 SAVEPOINT sp_loop，那所有回滚都只退到最后一次迭代的起点。
- 命名必须带上下文和唯一性标识，例如：
sp_insert_user_123、sp_update_stock_batch_20260930 - 避免用变量拼接名（如
CONCAT('sp_', @id)），MySQL 不支持动态SAVEPOINT名；SQL Server 可用@savepoint_var变量，但需确保类型为varchar(32)且内容合法 - 若需循环中独立回滚，改用不同名称或在每次循环末尾
RELEASE SAVEPOINT
ROLLBACK TO SAVEPOINT 后锁不释放，别误以为“子事务”已退出
执行 ROLLBACK TO sp_after_header 后，数据变更被撤销，但 InnoDB **不会释放该保存点之后获得的行锁**。比如你在保存点后做了 INSERT，回滚后那行的主键锁仍持有；如果之后又做 SELECT ... FOR UPDATE，锁范围可能扩大，其他事务仍会被阻塞。
这不是 bug，是设计使然：保存点不是事务嵌套，只是 undo 日志的一个偏移标记。整个事务仍是单一线程、单一锁空间。
- 验证是否真回滚？别信返回的
Query OK，直接SELECT查表；查锁要用SELECT * FROM information_schema.INNODB_TRX - DDL（
ALTER TABLE、DROP INDEX）会隐式提交事务，导致所有保存点立即失效——哪怕你把它写在IF分支里也一样 - SQL Server 中，
ROLLBACK TO savepoint_name会释放大部分锁，但升级过的锁（如从行锁升为页锁）可能保留，需注意隔离级别影响
存储过程异常退出时，SAVEPOINT 清理靠显式 RELEASE 或事务终结
存储过程结束（正常或异常）时，不会自动清理中间设的 SAVEPOINT。它们一直留到事务结束（COMMIT 或全量 ROLLBACK）才消失。这意味着：如果你在过程中设了 sp1，又 ROLLBACK TO sp1，但没 RELEASE SAVEPOINT sp1，下次同名再设就覆盖——而你可能根本没意识到旧状态已丢。
更隐蔽的问题是：某些连接池（如 HikariCP）复用连接时，若上个请求没彻底结束事务，当前请求一执行 SAVEPOINT 就可能因事务状态混乱而失败。
- 建议在确认某段逻辑不会再回滚时，立刻
RELEASE SAVEPOINT sp_name - 异常处理块中，
ROLLBACK TO后若要继续执行，最好紧接着RELEASE SAVEPOINT，避免干扰后续逻辑 - SQL Server 中，
RELEASE SAVEPOINT不可用变量名，只能用字面量；MySQL 支持变量，但需确保变量值是合法标识符
实际中最容易被忽略的一点：保存点的生命周期完全绑定于事务，而不是存储过程作用域。函数或触发器内部设的 SAVEPOINT，退出即销毁，外层不可见——但这不代表它没影响：它可能已修改了 undo 链或 binlog offset，只是你无法再引用罢了。
