mysql如何处理高并发下的死锁问题_分析死锁日志与调整事务隔离级别-mysql教程-PHP中文网

MySQL 默认不开启死锁日志，需启用 innodb_print_all_deadlocks 才能输出完整死锁信息至错误日志；该参数不影响性能，建议长期开启，关键字段包括事务ID、锁类型、表索引及SQL片段。

mysql如何处理高并发下的死锁问题_分析死锁日志与调整事务隔离级别

怎么看 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 ，在 REPEATABLE READ 下会加 gap lock + next-key lock；在 READ COMMITTED 下 gap lock 被禁用，但若 WHERE 条件无法走索引，可能升级为全表扫描+行锁，锁更多行，死锁概率不降反升。

真正有效的调整是：确保 WHERE 条件必走索引（避免锁整张表）
检查执行计划：EXPLAIN 看 type 是否为 range/ref，而非 ALL
READ COMMITTED 只对“非唯一条件的范围更新”有明确收益，其他情况需实测验证

怎么写事务才能减少死锁概率

死锁本质是多个事务以不同顺序访问相同资源。最有效的方式不是调参数，而是统一访问顺序——哪怕只是加个 ORDER BY。

比如批量更新用户余额，两个事务分别执行：

MySQL8 CRM Schema Design Expert

面向 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 导致嵌套锁）。

这类问题靠日志看不出，必须代码+日志联动排查。