MySQL不支持真正嵌套事务，框架用SAVEPOINT模拟但共享锁空间，导致死锁风险加剧；应拆分独立事务、合并单事务并排序加锁或应用层加锁，并检查索引、锁记录与savepoint命名唯一性。
MySQL 本身不支持嵌套事务，所谓“嵌套”只是框架模拟的语义，底层仍是一次真实事务 + 多个 SAVEPOINT。死锁不是因为用了“嵌套写法”，而是多个事务在并发下对同一组行加锁顺序不一致，又叠加了长事务、外键约束或未索引子查询等放大因素。
为什么框架的嵌套事务会加剧死锁风险
Doctrine、Laravel、ThinkPHP 等框架用 SAVEPOINT 模拟嵌套，但它们无法改变一个根本事实：所有 SAVEPOINT 都共享同一个事务上下文和锁空间。一旦外层事务未提交，所有内层 SAVEPOINT 的修改都处于同一把全局锁之下。
- 事务 A 在
SAVEPOINT sp1更新了user_id=100，又在sp2更新了order_id=500 - 事务 B 反向操作：先
SAVEPOINT sp1更新order_id=500，再sp2更新user_id=100 - 两个事务都在等对方释放行锁 → 死锁触发
更危险的是，开发者容易误以为“内层事务 rollback 到 savepoint 就安全了”，其实锁并未释放，只是回滚了数据变更，行锁仍被持有到外层 commit/rollback。
重构嵌套事务的三个实操方向
核心原则：消灭逻辑上的“嵌套感”，让事务边界清晰、资源访问顺序确定、锁持有时间最短。
-
拆成独立事务：把原内层事务逻辑抽成单独函数，显式开启/提交，用幂等设计兜底（如先查再 insert、用
INSERT ... ON DUPLICATE KEY UPDATE） -
合并为单事务 + 显式排序：若必须原子性，就把所有涉及的
UPDATE/SELECT FOR UPDATE合并在一个事务里，并强制按主键或唯一索引升序执行（例如ORDER BY id ASC），避免优化器因执行计划差异导致加锁顺序随机 -
用应用层锁兜底：对高冲突资源（如账户余额、库存），在事务外用 Redis 锁（
SET key value NX PX 5000）抢占，成功后再进数据库事务；失败则快速重试或降级
排查时重点看这三个地方
别只盯着代码里写了几个 beginTransaction()，真正要挖的是 InnoDB 实际加了什么锁、锁了哪些行。
- 执行
SHOW ENGINE INNODB STATUS;，翻到LATEST DETECTED DEADLOCK，确认死锁双方 SQL 和等待的index record lock行 - 对涉及的
UPDATE/DELETE语句跑EXPLAIN FORMAT=tree（MySQL 8.0+）或EXPLAIN，检查type是否为const/range，避免ALL或index全扫加锁 - 查表结构，确认 WHERE 条件字段是否都有索引——特别是外键列、子查询中的关联字段，没索引会触发间隙锁（
Gap Lock）扩大锁定范围
最容易被忽略的一点：框架里 savepoint 的名字如果重复（比如都叫 trans2），在并发下可能意外覆盖，导致 rollback 错位。检查 ORM 源码中生成 savepoint 名的逻辑，确保带唯一标识（如 request ID 或微秒时间戳）。
