MySQL不支持事务嵌套，第二次START TRANSACTION会隐式提交前一事务；唯一可行方案是SAVEPOINT，它在当前事务内设标记点，配合ROLLBACK TO SAVEPOINT实现局部回滚，且需调用方控制事务边界。
MySQL根本不支持事务嵌套，所谓“内层事务回滚不影响外层”是错觉。你在存储过程里写两次 START TRANSACTION，第二次会直接隐式提交第一次未提交的变更，然后开新事务——不是挂起，是清掉再重来。
为什么START TRANSACTION在存储过程中不能嵌套
MySQL事务模型是扁平的：同一连接只允许一个活跃事务。存储过程内部调用另一个含 START TRANSACTION 的过程，原事务立刻结束，已执行但未提交的语句（比如 INSERT）会被强制落库。
- 典型错误现象：
ERROR 1305 (42000): SAVEPOINT does not exist，或发现ROLLBACK只撤了最后一段，前面的数据却已经写进表里 - 更隐蔽的问题：第二层
START TRANSACTION后，SELECT查不到刚插入的记录——因为被隐式提交，又受隔离级别影响查不到了 - 根本原因：MySQL没有事务栈，
BEGIN ... END块只是语法容器，不改变事务状态
SAVEPOINT 是唯一可行的“伪嵌套”手段
SAVEPOINT 不开启新事务，只在当前事务内打标记点，配合 ROLLBACK TO SAVEPOINT 实现局部回滚。它才是存储过程中做逻辑分段的正确姿势。
- 定义保存点：
SAVEPOINT sp_after_user;（名字必须唯一，重复会覆盖，不报错） - 回滚到该点：
ROLLBACK TO SAVEPOINT sp_after_user;（事务仍活跃，后续必须COMMIT或ROLLBACK） - 释放保存点（可选）：
RELEASE SAVEPOINT sp_after_user;（避免内存累积，但不释放也不影响功能） - 注意：
COMMIT或整个事务ROLLBACK会自动清除所有SAVEPOINT
存储过程中用SAVEPOINT的实操要点
关键不是“怎么设点”，而是“谁控事务边界”。推荐模式：调用方开启事务，存储过程只负责划分逻辑段并配异常处理器。
-
DECLARE EXIT HANDLER FOR SQLEXCEPTION必须写在SAVEPOINT之前，否则异常触发时找不到对应保存点 - 不要把
START TRANSACTION写进存储过程体；它应由应用层或上层过程统一控制 - SAVEPOINT 名不能是变量（如
sp_@i），MySQL 不支持动态保存点名 - 高频小事务中避免每行都设点，按业务语义块设（例如“用户创建+权限分配”为一个块）
容易被忽略的锁与性能细节
ROLLBACK TO SAVEPOINT 不释放行锁，锁会一直持有直到整个事务 COMMIT 或最终 ROLLBACK。高并发场景下，这可能引发锁等待甚至死锁。
- 验证锁残留可用：
SELECT * FROM performance_schema.data_locks WHERE THREAD_ID = ? - 逻辑特别复杂或步骤多时，优先考虑拆成多个短事务，而不是硬靠
SAVEPOINT模拟嵌套 - MySQL 5.7+ 对
SAVEPOINT支持稳定，但 MyISAM 引擎不支持事务，自然也不支持SAVEPOINT
