self join 本身不导致死锁，但多事务中配合 update 或 for update 且加锁顺序不一致时极易死锁；根本原因是同一表不同别名被以不同逻辑顺序访问，形成循环等待，需通过拆分为有序单表更新或 straight_join 强制驱动表来规避。
Self Join 本身不会导致死锁，但当它出现在事务中、配合 UPDATE 或 SELECT ... FOR UPDATE 且涉及多行交叉加锁时，极易触发死锁——根本原因是同一张表被不同事务以不同逻辑顺序访问，形成“自己等自己”的等待环。
为什么自连接更新容易死锁？
自连接不是语法问题，而是执行时的加锁行为出了问题。比如对用户表 users 执行：
UPDATE u1 SET u1.status = 'processed' FROM users u1 JOIN users u2 ON u1.manager_id = u2.id WHERE u2.department = 'tech' AND u1.status = 'pending';
这个语句在 InnoDB 中实际会按执行计划顺序（可能是 u2 先扫描再定位 u1）加锁。若另一个事务执行：
UPDATE u1 SET u1.salary = u1.salary * 1.1 FROM users u1 JOIN users u2 ON u1.id = u2.manager_id WHERE u2.status = 'active';
它的驱动表可能是 u1，加锁顺序就反过来了。两个事务同时运行，就可能：
- 事务A 持有 u2.id=100 行锁，等待 u1.id=200
- 事务B 持有 u1.id=200 行锁，等待 u2.id=100
→ 死锁成立。
- 自连接让一张表在单条 SQL 中出现两次，数据库必须为每个别名独立加锁，但优化器选的驱动表/访问路径不可控
- 没有显式索引提示时，
ON条件字段（如manager_id、id）若缺失索引，会触发全表扫描+大量间隙锁，冲突面指数级扩大 - MySQL 默认
REPEATABLE READ下，自连接范围查询极易激活Gap Lock，把本不该锁的索引空档也锁住
如何用拆分事务避免自连接死锁？
核心思路：把“一次扫两遍表”改成“先查后更”，由应用层控制顺序和锁粒度。
- 第一步：用只读查询拿到所有要更新的
u1.id列表，按id升序排序（强制统一顺序） - 第二步：用批量
UPDATE users SET status = 'processed' WHERE id IN (1,2,3,...) ORDER BY id更新 ——ORDER BY id能让 InnoDB 按主键顺序加锁，消除交叉 - 避免在事务里混用自连接读 + 单表更新：例如先
SELECT ... JOIN再UPDATE同一表，容易因读写路径不一致引发死锁 - 如果必须保留自连接逻辑，至少把读写分离：自连接只用于
SELECT，结果集交给应用处理后再发起幂等UPDATE
这样做的代价是多一次 round-trip，但换来的是确定性加锁顺序和极低死锁率。
什么时候该用 STRAIGHT_JOIN 强制驱动表？
仅当无法拆分事务（如遗留存储过程、ORM 封装过深），且你能确认某张别名始终应作为驱动表时才用 STRAIGHT_JOIN。例如：
UPDATE STRAIGHT_JOIN users u1 JOIN users u2 ON u1.manager_id = u2.id SET u1.status = 'processed' WHERE u2.department = 'tech';
这强制 MySQL 先扫 u2（部门索引快），再根据 manager_id 查 u1，所有事务都走同一条路径。
- 必须确保
u2.department有高效索引，否则STRAIGHT_JOIN会放大性能问题 - 不能依赖表书写顺序：不加
STRAIGHT_JOIN时，MySQL 8.0+ 可能因统计信息变化自动切换驱动表 - 上线前用
EXPLAIN FORMAT=TREE验证实际执行顺序，别信 SQL 文本顺序
最容易被忽略的细节：自连接中的 NULL 和索引失效
自连接常带 LEFT JOIN 或 ON ... IS NULL 条件，这类写法极易让索引失效：
-
ON u1.manager_id = u2.id OR u2.id IS NULL→ 优化器大概率放弃索引，退化为全表扫描 -
WHERE u2.id IS NULL在LEFT JOIN后过滤，可能让u2变成驱动表，而它没索引可走 - 一旦扫描全表，InnoDB 会对整个聚簇索引加锁（或大量间隙锁），死锁概率飙升
真正安全的做法是：把 IS NULL 判断提前到子查询或 CTE 中，并确保关联字段有非空约束+索引。否则，宁可拆成两个独立查询。
