MySQL不支持真正嵌套事务，第二次START TRANSACTION会隐式提交前一个事务；唯一模拟方式是使用SAVEPOINT实现局部回滚，ORM框架的“嵌套事务”实为基于SAVEPOINT的计数器机制。

MySQL 本身不支持真正的嵌套事务。你写两个 START TRANSACTION，第二个会隐式提交第一个——不是报错，而是“悄无声息地 commit”，导致外层 ROLLBACK 完全失效。

为什么 START TRANSACTION 会自动提交上一个事务？

这是 MySQL 的硬性行为，不是 bug，是设计如此。只要当前连接处于活跃事务中，再执行 START TRANSACTION、BEGIN 或 BEGIN WORK，MySQL 就会立即执行一次隐式 COMMIT，然后开启新事务。

• 哪怕你只写了 BEGIN 两次，也等价于：

  BEGIN;
  -- 做点事
  BEGIN; -- 此时前一个事务已 COMMIT

• autocommit=0 是前提，否则连第一个事务都启不动
• MyISAM 引擎完全无视事务语句，必须用 InnoDB

想“模拟嵌套”？用 SAVEPOINT 是唯一靠谱方案

MySQL 支持 SAVEPOINT，它不是嵌套事务，但能实现“局部回滚”，这是框架（如 Laravel、ThinkPHP）所谓“嵌套事务”的底层原理。

• SAVEPOINT sp1;：打一个标记点
• ROLLBACK TO sp1;：回滚到该点，之后的修改丢弃，但事务仍活跃
• RELEASE SAVEPOINT sp1;：删除标记点（非必需）
• 注意：SAVEPOINT 不能跨连接，也不能在存储过程/触发器里滥用（可能触碰 max_sp_recursion_depth 限制）

示例：

BEGIN;
INSERT INTO users (name) VALUES ('Alice');
SAVEPOINT after_alice;
INSERT INTO users (name) VALUES ('Bob');
-- 发现 Bob 不合法，只撤回这一步
ROLLBACK TO after_alice;
COMMIT;

ORM 框架的“嵌套事务”其实是障眼法

ThinkPHP、Laravel 等框架的 startTrans() / DB::transaction() 看似支持嵌套，实则靠计数器 + SAVEPOINT 实现：

• 第一次调用 → 执行 BEGIN
• 第二次调用 → 执行 SAVEPOINT trans2
• 回滚内层 → 执行 ROLLBACK TO trans2
• 只有最外层 commit() 或 rollback() 才真正操作 MySQL 事务状态
• 如果框架没检测到 supportSavepoint()（比如某些低版本 MySQL 或禁用模式），嵌套会直接退化成“每次 begin 都 commit 上次”，数据一致性崩塌

最容易被忽略的三个坑

很多线上事故不是因为不会写事务，而是栽在这几个细节上：

• 触发器里改数据 → 可能间接激活另一个触发器，形成嵌套调用，受 max_sp_recursion_depth 限制，默认为 0（禁止递归），超限报错 Error 1423
• 同一张表的 BEFORE 触发器里再 UPDATE 自身 → 直接报 Error 1420（MySQL 明确禁止）
• 没配好异常传播：比如 try/catch 里吞了异常却不 throw，导致框架以为“一切正常”，最终跳过 rollback()

事务不是套娃游戏，MySQL 给的工具就两样：BEGIN/COMMIT/ROLLBACK 和 SAVEPOINT/ROLLBACK TO。把它们用对，比追求“嵌套语法糖”重要得多。