MySQL存储过程不支持真正嵌套事务，START TRANSACTION会隐式提交前一事务；唯一可控的局部回滚手段是SAVEPOINT，需先声明异常处理器再设点，且不释放锁。

SQL 存储过程中无法实现真正的多层嵌套事务，START TRANSACTION 或 BEGIN TRANSACTION 在过程内执行会隐式提交前一个事务，不是压栈，是中断重置。唯一可控的“分层回滚”手段是 SAVEPOINT，它不开启新事务，只在当前事务中打标记点。

为什么存储过程里写 BEGIN TRANSACTION 会破坏外层事务

MySQL 和 SQL Server 都采用扁平事务模型：单连接同一时刻只能有一个活跃事务。你在存储过程中执行 START TRANSACTION，数据库会立刻提交调用方已开启但尚未 COMMIT 的事务，再新建一个——外层事务就此终结。

• 典型错误现象：INSERT 后进过程再 START TRANSACTION，结果发现那条 INSERT 已落库、不可被后续 ROLLBACK 撤销
• SQL Server 中还会报错 Msg 266, Level 16, State 2: Transaction count after EXECUTE indicates a mismatch
• MySQL 存储函数里直接写 START TRANSACTION 会触发 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger

SAVEPOINT 必须配合异常处理器按顺序声明

在 MySQL 存储过程中使用 SAVEPOINT 时，DECLARE EXIT HANDLER FOR SQLEXCEPTION 必须出现在 SAVEPOINT 语句之前，否则 handler 触发时可能找不到保存点，导致 ROLLBACK TO SAVEPOINT 报 ERROR 1305 (42000): SAVEPOINT does not exist。

• 正确顺序：DECLARE EXIT HANDLER ...; SAVEPOINT sp_main;
• 保存点名必须是字面量标识符，不能是变量（如 @sp_name），MySQL 不支持动态命名；若真需拼接，得用 PREPARE + EXECUTE，但有注入风险，慎用
• 同名 SAVEPOINT 会被后一次覆盖（不报错），建议带上下文命名，比如 sp_update_user_profile

ROLLBACK TO SAVEPOINT 不释放锁，长事务中极易阻塞

ROLLBACK TO SAVEPOINT 只撤销数据变更，不会释放该保存点之后语句所持有的行锁、间隙锁。若在长事务中频繁设点+回滚，锁会持续累积，轻则拖慢并发，重则触发 ERROR 1205 (HY000): Deadlock found when trying to get lock。

• 验证锁残留可用：SELECT * FROM performance_schema.data_locks WHERE THREAD_ID = ...
• 执行 ROLLBACK TO SAVEPOINT sp_x 后，事务仍处于活跃状态，必须显式 COMMIT 或 ROLLBACK 才能释放全部锁
• 高并发或逻辑复杂场景，优先拆成多个短事务，而不是依赖 SAVEPOINT 模拟嵌套

真正关键的一点是：事务边界应由应用层或最外层调用 SQL 控制，存储过程只负责逻辑分段与错误通知。把 START TRANSACTION 塞进过程体，等于主动放弃事务一致性控制权。