MySQL 默认不开启死锁日志，需启用 innodb_print_all_deadlocks 才能输出完整死锁信息至错误日志；该参数不影响性能，建议长期开启，关键字段包括事务ID、锁类型、表索引及SQL片段。
怎么看 MySQL 的死锁日志
MySQL 默认不开启死锁日志输出，得手动打开 innodb_print_all_deadlocks 才能看到完整死锁信息。它不会写进 error.log，而是追加到 MySQL 错误日志里（路径由 log_error 配置决定）。
常见错误现象：应用报 Deadlock found when trying to get lock; try restarting transaction，但日志里找不到上下文——大概率是这个开关没开。
- 临时启用：
SET GLOBAL innodb_print_all_deadlocks = ON; - 永久生效：在
my.cnf的[mysqld]段加一行innodb_print_all_deadlocks = ON - 注意：该参数不影响性能，只增加日志体积，建议线上长期开启
死锁日志里关键字段包括：每个事务的 TRANSACTION ID、持有/等待的 LOCK 类型（如 RECORD LOCKS）、涉及的表和索引、SQL 语句片段。重点看「WAITING FOR THIS LOCK TO BE GRANTED」和「HOLDS THE LOCK(S)」两块，能快速定位谁锁了谁、为什么循环等待。
为什么降低隔离级别不一定能解决死锁
很多人第一反应是把 REPEATABLE READ 改成 READ COMMITTED，觉得“读不加锁”就能少死锁。实际并非如此——InnoDB 在 READ COMMITTED 下依然会对更新/删除加行锁，且间隙锁（gap lock）行为有变化，反而可能扩大锁范围。
典型场景：两个事务并发执行 UPDATE t SET x=1 WHERE id > 100 AND id ，在 <code>REPEATABLE READ 下会加 gap lock + next-key lock；在 READ COMMITTED 下 gap lock 被禁用，但若 WHERE 条件无法走索引，可能升级为全表扫描+行锁，锁更多行，死锁概率不降反升。
- 真正有效的调整是：确保 WHERE 条件必走索引（避免锁整张表）
- 检查执行计划：
EXPLAIN看type是否为range/ref，而非ALL -
READ COMMITTED只对“非唯一条件的范围更新”有明确收益，其他情况需实测验证
怎么写事务才能减少死锁概率
死锁本质是多个事务以不同顺序访问相同资源。最有效的方式不是调参数，而是统一访问顺序——哪怕只是加个 ORDER BY。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
比如批量更新用户余额，两个事务分别执行：
UPDATE user SET balance = balance + 10 WHERE id IN (5, 2, 8);
MySQL 内部处理顺序不确定，A 事务按 2→5→8 加锁，B 事务按 5→8→2 加锁，就容易形成环。改成：
UPDATE user SET balance = balance + 10 WHERE id IN (5, 2, 8) ORDER BY id;
就能强制锁顺序一致。
- 所有涉及多行修改的 SQL，显式加
ORDER BY（主键或唯一索引优先） - 事务内操作尽量短：避免在事务里调外部 API、做复杂计算、或 sleep
- 更新前先
SELECT ... FOR UPDATE？谨慎！它可能提前加锁，反而扩大冲突面；不如直接UPDATE，让 InnoDB 自动判断锁粒度 - 应用层捕获
Deadlock found when trying to get lock后重试，但最多 2–3 次，避免雪崩
死锁分析中最容易被忽略的一点
死锁日志里显示的 SQL 往往是“最后执行的那条”，但它未必是起因。真正的问题常藏在事务开头——比如一个事务先执行了 SELECT ... LOCK IN SHARE MODE 拿了共享锁，后面再升级为排他锁，而另一个事务刚好反向操作。
所以不能只盯着报错那条 SQL，要结合应用代码还原整个事务边界：从 BEGIN 到 COMMIT 做了哪些操作、是否跨多个 DAO 方法、有没有隐式事务（如 Spring 的 @Transactional 传播行为设成了 REQUIRES_NEW 导致嵌套锁）。
这类问题靠日志看不出，必须代码+日志联动排查。
