MySQL不支持真正的嵌套事务，InnoDB仅支持扁平式事务模型；BEGIN后再次BEGIN会隐式提交当前事务并开启新事务，而非创建子事务；可通过SAVEPOINT实现局部回滚模拟嵌套效果。
MySQL 本身不支持真正的嵌套事务
MySQL 的 InnoDB 存储引擎只支持**扁平式事务模型**，没有原生的嵌套事务（nested transaction）语义。所谓 BEGIN / START TRANSACTION 后再执行一次 BEGIN，并不会创建子事务，而只是隐式提交当前事务并开启新事务——这和你预期的“保存点回滚到某一层”完全不同。
用 SAVEPOINT 模拟嵌套事务的常见做法
虽然不能真正嵌套，但可以通过 SAVEPOINT 实现局部回滚效果，这是最贴近“嵌套”需求的替代方案：
-
SAVEPOINT sp1设置一个保存点，后续可选择性回滚至此 -
ROLLBACK TO SAVEPOINT sp1只撤销该保存点之后的操作，不影响之前已执行的语句 -
RELEASE SAVEPOINT sp1显式释放保存点（非必须，事务结束时自动清理） - 注意：
ROLLBACK TO SAVEPOINT不会释放锁，也不影响已加的行锁或间隙锁
误用 BEGIN 造成隐式提交的典型错误
以下代码看似“嵌套”，实则危险：
START TRANSACTION; INSERT INTO t1 VALUES (1); BEGIN; -- ❌ 这里会隐式提交上一个事务，并开启新事务 INSERT INTO t1 VALUES (2); ROLLBACK; -- 只回滚了第二条 INSERT，第一条已永久写入
这种写法在开发中容易被当成“子事务”使用，结果导致数据不一致。尤其在存储过程中多次调用 BEGIN，极易踩坑。
存储过程里想“模拟嵌套”要格外小心
MySQL 存储过程中无法捕获外部事务状态，START TRANSACTION 总是会中断当前事务上下文。如果需要过程内可控回滚：
- 统一由调用方控制事务边界，过程内部只设
SAVEPOINT - 避免在过程中使用
COMMIT或ROLLBACK，除非明确知道自己在终结整个事务 - 注意：存储函数中禁止执行显式事务控制语句（
START/COMMIT/ROLLBACK），否则报错ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger
真正复杂的事务编排，建议把逻辑提到应用层，用连接池 + 手动 begin/commit/rollback 控制，比硬塞进存储过程更清晰、更可控。
