MySQL不支持真正嵌套事务，START TRANSACTION会隐式提交前一事务；唯一可行的局部回滚方案是SAVEPOINT，它仅在当前事务内设标记点，配合ROLLBACK TO SAVEPOINT使用，且需确保AUTOCOMMIT=0。
MySQL 存储过程中不能真正嵌套事务，START TRANSACTION 会隐式提交前一个事务；唯一可行的“局部回滚”方案是 SAVEPOINT。
为什么 START TRANSACTION 在存储过程里会导致意外提交
你在存储过程里写两次 START TRANSACTION，第二次执行时，MySQL 会自动提交第一次开启但尚未 COMMIT 的事务——不是挂起，是直接落库。这意味着：
- 外层逻辑还没走完，中间插入/更新的数据已经不可逆地写入磁盘
- 后续
ROLLBACK只能回滚第二次事务里的操作，第一次的变更早已生效 - 常见错误现象：
ERROR 1305 (42000): SAVEPOINT does not exist或者发现“回滚后数据还在”，其实是前一段早就被隐式提交了
SAVEPOINT 是唯一安全的“伪嵌套”手段
SAVEPOINT 不开启新事务，只在当前活跃事务内打一个标记点。它轻量、可控，且符合 MySQL 的扁平事务模型：
- 定义：用
SAVEPOINT sp_name（名字必须在同一事务内唯一，重复会覆盖） - 回滚：用
ROLLBACK TO SAVEPOINT sp_name，仅撤回该点之后的操作 - 释放（可选）：用
RELEASE SAVEPOINT sp_name，避免长期占用内存 - 注意：
COMMIT或整个事务ROLLBACK会自动清除所有SAVEPOINT
存储过程中怎么正确用 SAVEPOINT
关键原则：事务边界由调用方控制，存储过程内部只负责分段和标记。典型结构如下：
DELIMITER //
CREATE PROCEDURE proc_do_something(IN p_user_id INT)
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK TO SAVEPOINT sp_main;
RESIGNAL;
END;
<p>-- 假设调用方已 START TRANSACTION
SAVEPOINT sp_main;</p><p>INSERT INTO users (id) VALUES (p_user_id);
SAVEPOINT sp_after_user;</p><p>INSERT INTO profiles (user_id, bio) VALUES (p_user_id, 'default');
-- 如果这句失败，只回滚 profile 插入，user 记录保留
IF some_condition THEN
ROLLBACK TO SAVEPOINT sp_after_user;
END IF;
END //
DELIMITER ;- 不写
START TRANSACTION或COMMIT在过程体内 - 每个
SAVEPOINT名要带上下文标识（如sp_after_user），避免跨逻辑块冲突 - 异常处理器里用
ROLLBACK TO SAVEPOINT，而非ROLLBACK全局回滚 - 调用方需确保
AUTOCOMMIT = 0，否则SAVEPOINT无效
容易被忽略的锁与性能细节
执行 ROLLBACK TO SAVEPOINT 后，事务仍处于活跃状态，已持有的行锁不会自动释放——除非显式 COMMIT 或 ROLLBACK。这意味着：
- 高并发场景下，长时间未结束的事务可能持续阻塞其他会话
- 用
SELECT * FROM performance_schema.data_locks WHERE THREAD_ID = ...可验证锁是否残留 - 逻辑越复杂，越建议拆成多个短事务，而不是堆满
SAVEPOINT依赖“伪嵌套”
真正难处理的从来不是语法，而是事务边界归属不清：谁开启、谁捕获异常、谁决定最终提交或放弃——这些必须在应用层或调用链最外侧统一约定，不能靠存储过程自己“偷偷”管。
