mysql死锁日志中，transaction行标识事务id与状态，waiting for this lock to be granted明确指出等待的锁类型及目标记录，需结合holds the lock(s)和最近dml语句定位索引与锁冲突点。
怎么看 MySQL 死锁日志里的 TRANSACTION 和 WAITING FOR THIS LOCK TO BE GRANTED
死锁日志不是报错信息，而是 MySQL 自动检测并回滚其中一个事务后留下的诊断快照。关键看三块：*** (1) 和 *** (2) 分别代表两个冲突事务，每块里先有 TRANSACTION 行（含事务 ID、活跃时间、状态），接着是 mysql tables in use 和 LOCK WAIT —— 这说明它卡在等锁；最后的 WAITING FOR THIS LOCK TO BE GRANTED 行，明确写出它想申请哪行记录的什么锁（比如 X locks rec but not gap），而上面紧邻的 HOLDS THE LOCK(S) 就是另一个事务正拿着的锁。
常见错误是只扫一眼 Deadlock found when trying to get lock 就去查业务逻辑，却忽略真正卡点在哪一行、哪个索引上。实际要顺着 WAITING FOR 往上找同一事务里最近的 INSERT/UPDATE/DELETE 语句，再结合表结构确认它走的是哪个索引。
- 用
SHOW ENGINE INNODB STATUS\G查最新死锁，但注意该命令只保留最后一次，线上需配合定期采集 - 日志里出现
gap before rec或insert intention，大概率是范围锁 + 插入冲突，和唯一索引无关，和非唯一二级索引的间隙锁有关 - 如果
WAITING FOR指向的是主键（PRIMARY），说明 WHERE 条件最终定位到了聚簇索引行，但锁可能由二级索引引发（比如 UPDATE 带非主键条件）
为什么加了索引还是死锁？重点查 WHERE 条件是否命中索引、是否用上最左前缀
索引没被用上，MySQL 就会降级为全表扫描或索引扫描，锁住大量无关行，大幅提高死锁概率。不是“建了索引就安全”，而是“每次执行都得真走这个索引”。用 EXPLAIN 看执行计划，重点关注 type（至少要是 range 或 ref）、key（是否显示你期望的索引名）、rows（扫描行数是否合理）。
典型翻车场景：对 status = ? AND create_time > ? 建了联合索引 (status, create_time)，但查询时只传了 create_time —— 最左前缀失效，索引直接不用；或者用了 OR 拆分条件，导致无法走索引合并（index_merge 在高并发下反而更易争抢）。
-
WHERE中对字段做函数操作（如DATE(create_time) = '2024-01-01'）会跳过索引，改用create_time >= '2024-01-01' AND create_time - 字符串字段用数字查询（如
user_id = 123而user_id是VARCHAR）会触发隐式类型转换，索引失效 - 区分
=和IN：单值=可走索引，但IN列表过大（如几百个 ID）可能让优化器放弃索引，改走全表
SELECT ... FOR UPDATE 和 UPDATE 的锁行为差异：别以为加了 FOR UPDATE 就万事大吉
SELECT ... FOR UPDATE 和直接 UPDATE 在锁粒度上可能完全不同。前者只锁扫描到的行（即使用了索引），后者在满足条件的前提下，还会对“可能插入新行的间隙”加插入意向锁 —— 这正是很多死锁的源头。例如对 order_no = 'xxx' 加锁，如果该值不存在，SELECT ... FOR UPDATE 不锁任何记录（返回空），但 INSERT INTO ... VALUES ('xxx', ...) 会在对应间隙加锁，此时另一个事务若也尝试插入同个 order_no，就会形成间隙锁 vs 插入意向锁的冲突。
更隐蔽的是，SELECT ... FOR UPDATE 如果没走索引，会升级成表级锁（在 RC 隔离级别下虽不常见，但在某些执行计划下仍可能）；而 UPDATE 即使走索引，若 WHERE 条件匹配多行，也会锁住所有扫描行及间隙，范围越大越危险。
- 避免在事务开头用
SELECT ... FOR UPDATE锁一个“可能不存在”的值，然后判断再插入 —— 改用INSERT ... ON DUPLICATE KEY UPDATE更原子、更少锁 - 如果必须用
SELECT ... FOR UPDATE，确保 WHERE 条件能精确命中唯一索引，且该记录大概率存在（减少空扫描+间隙锁） - 在 RR 隔离级别下，
UPDATE语句即使只更新一行，也会锁住该行前后间隙（防止幻读），这是默认行为，没法关
死锁高频发生时，先盯住 innodb_lock_wait_timeout 和事务粒度
调大 innodb_lock_wait_timeout（默认 50 秒）只是掩盖问题，不能减少死锁次数。真正有效的是缩短单个事务持有锁的时间：把大事务拆成小事务，把非数据库操作（如 HTTP 调用、文件写入）移出事务块，把 SELECT 提前、DML 集中在事务末尾。
另一个常被忽略的点是事务开启方式。ORM 框架（如 MyBatis、Spring）里用 @Transactional 注解，若传播行为是 REQUIRED，嵌套调用会复用同一事务，导致锁持有时间远超预期。同时，长连接中未显式提交的事务，可能让锁一直挂着，直到连接超时才释放。
- 检查慢查询日志，找出执行时间 > 1s 的
UPDATE/DELETE，它们往往是锁持有大户 - 用
SELECT * FROM information_schema.INNODB_TRX查当前长事务，重点关注TRX_STARTED和TRX_ROWS_LOCKED - 批量更新别用循环单条
UPDATE，改用INSERT ... ON DUPLICATE KEY UPDATE或临时表 JOIN，减少网络往返和事务开销
死锁本身不可完全避免，但频繁死锁一定意味着某处索引没走对、事务包得太宽、或者业务逻辑在多个维度上以不同顺序访问相同资源 —— 日志里那个 *** (1) 和 *** (2) 的 SQL 执行顺序，就是破局的关键线索。
