mysql-deadlock

MySQL 死锁的定位与处理

现象

应用报 Deadlock found when trying to get lock; try restarting transaction（ERROR 1213）。事务被 InnoDB 选为牺牲者回滚，通常不是数据库坏了，而是加锁顺序或索引问题。

快速定位

SHOW ENGINE INNODB STATUS\G
SHOW VARIABLES LIKE 'innodb_print_all_deadlocks';
SELECT * FROM performance_schema.data_locks;
SELECT * FROM performance_schema.data_waits;

错误日志：

tail -100 /var/log/mysql/error.log | grep -i deadlock

常见根因

1. 不同事务以相反顺序更新同一批行。
2. 缺索引导致锁范围扩大，产生间隙锁。
3. 事务过长，持有锁等待外部调用。
4. 批量更新顺序不一致或并发过高。
5. 隔离级别和唯一键冲突导致额外锁。

修复

• 统一业务加锁顺序，按主键或固定字段排序后更新。
• 缩短事务，把外部调用移出事务。
• 补索引，减少扫描范围和间隙锁。
• 捕获 1213 并做有限重试；重试要退避且保证幂等。
• 评估隔离级别，但不要为了“消灭死锁”盲目改。
• 用 innodb_print_all_deadlocks 持续记录，按 SQL 模式治理。

相关命令

• mysql — 执行诊断 SQL
• journalctl — 错误日志
• mysqladmin — 服务状态

读完自测

合上页面，先回答，再展开对照。

1. 应用报 ERROR 1213，是否说明数据库本身坏了？
2. 如何让 MySQL 持续记录死锁信息？
3. 治理死锁的两个关键方向是什么？