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 控制，比硬塞进存储过程更清晰、更可控。
