MySQL死锁是多个事务相互等待对方释放锁，导致无法继续执行的现象。排查死锁的关键在于获取死锁发生时的详细信息，并分析事务之间的资源竞争关系。以下是常用的排查方法和步骤。
查看死锁日志（InnoDB状态信息）
MySQL的InnoDB引擎会自动检测死锁并回滚其中一个事务。可以通过以下命令查看最近一次死锁的详细信息：
SHOW ENGINE INNODB STATUS\G输出结果中包含一个“LATEST DETECTED DEADLOCK”部分，其中会显示：
死锁发生的时间 两个或多个事务的ID、线程ID、等待状态 每个事务持有的锁和正在等待的锁 涉及的SQL语句 事务堆栈和表/行锁信息通过这部分信息可以清楚看到哪个事务在等待哪条记录的锁，以及谁持有该锁，从而定位冲突源头。
启用死锁日志记录（错误日志）
确保MySQL配置中开启了错误日志，并且InnoDB能将死锁信息写入日志文件。检查my.cnf配置：
log_error = /var/log/mysql/error.logInnoDB默认会在发生死锁时将详细信息输出到错误日志中，便于长期监控和事后分析。你可以在日志中搜索“Deadlock found”关键字来快速定位相关记录。
分析事务执行顺序和SQL语句
根据死锁日志中的SQL语句，分析事务的操作顺序是否合理。常见引发死锁的场景包括：
多个事务以不同顺序访问同一组数据行 长事务持有锁时间过长 未使用索引导致全表扫描，加锁范围扩大 间隙锁（gap lock）与插入意向锁冲突建议：统一访问表的顺序，避免跨事务交叉更新；尽量缩短事务执行时间；确保WHERE条件走索引，减少锁的粒度。
使用Performance Schema监控锁等待
MySQL 5.6及以上版本可通过Performance Schema查看实时的锁等待情况：
SELECT * FROM performance_schema.data_locks;SELECT * FROM performance_schema.data_lock_waits;这些表展示了当前持有的锁和锁等待关系，有助于在死锁发生前发现潜在问题。
预防和优化建议
除了排查，更重要的是减少死锁发生的概率：
保持事务简短，尽快提交或回滚 按固定顺序操作多张表或多行数据 在应用层重试机制中处理死锁异常（如捕获1213错误码） 合理设计索引，避免不必要的行锁升级 必要时使用SELECT ... FOR UPDATE或
LOCK IN SHARE MODE显式控制加锁行为
基本上就这些。关键是利用
SHOW ENGINE INNODB STATUS获取现场信息，结合SQL逻辑分析原因，再通过优化事务结构和索引来降低风险。
