首先查看SHOW ENGINE INNODB STATUS中的LATEST DETECTED DEADLOCK信息，结合innodb_print_all_deadlocks日志、information_schema或performance_schema中的锁等待数据，分析死锁原因，常见为事务操作顺序不一致、缺失索引或长事务，建议统一访问顺序、添加索引、缩短事务并重试机制。
MySQL出现锁死（死锁）时，通常会导致事务阻塞、请求超时或报错。要快速定位并解决问题，需要结合系统表、日志和SQL执行情况综合分析。以下是实用的排查方法。
查看最近的死锁信息
MySQL的InnoDB存储引擎会记录最近一次的死锁详情，可以通过以下命令查看：
SHOW ENGINE INNODB STATUS\G在输出结果中查找LATEST DETECTED DEADLOCK部分，这里会显示：
- 发生死锁的时间
- 两个或多个事务的等待关系
- 每个事务持有的锁和等待的锁
- 导致死锁的SQL语句
这是最直接的排查入口，能帮助你还原死锁发生的场景。
启用死锁日志（innodb_print_all_deadlocks）
默认情况下，SHOW ENGINE INNODB STATUS只保留最后一次死锁信息。为了长期监控，建议开启将死锁记录到错误日志的功能：
SET GLOBAL innodb_print_all_deadlocks = ON;开启后，所有死锁都会被写入MySQL错误日志文件，便于后续分析和审计。适用于生产环境频繁出现死锁的场景。
查询information_schema中的锁等待状态
可以实时查看当前的锁等待情况：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
注意：这些表在新版本MySQL中已被标记为废弃，但在MySQL 5.7及之前版本仍可使用。MySQL 8.0推荐使用performance_schema代替。
- INNODB_TRX：查看正在运行的事务，重点关注长时间未提交的事务
- INNODB_LOCKS：查看每个事务持有的锁
- INNODB_LOCK_WAITS：显示哪个事务在等待哪个锁
使用performance_schema分析锁（MySQL 8.0+）
在MySQL 8.0中，performance_schema提供了更强大的锁监控能力：
-- 开启相关消费者UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_waits%';
-- 查看锁等待事件
SELECT * FROM performance_schema.data_locks;
SELECT * FROM performance_schema.data_lock_waits;
data_locks表展示当前所有数据行上的锁信息，包括锁类型、索引、锁定范围等，是现代MySQL版本推荐的排查方式。
常见死锁原因与规避建议
根据排查结果，常见的死锁模式有：
- 事务按不同顺序访问多张表或同一表的多行数据
- 缺失索引导致扫描范围扩大，加锁过多
- 长事务持有锁时间过长
优化建议：
- 确保多个事务以相同顺序操作表
- 为WHERE条件添加合适索引，减少锁范围
- 避免在事务中执行耗时操作，及时提交
- 捕获死锁异常并重试事务（应用层处理）
基本上就这些。关键是要先从SHOW ENGINE INNODB STATUS入手，再结合日志和系统表确认细节。死锁无法完全避免，但通过合理设计可以大幅降低发生概率。
