死锁由事务相互等待锁导致，需通过show engine innodb status查看“latest detected deadlock”获取事务、锁和sql信息；2. 启用错误日志记录死锁详情，便于追溯；3. 分析sql执行顺序，避免无序访问、长事务和全表扫描；4. 使用performance schema监控data_locks和data_lock_waits实时锁状态；5. 优化建议包括缩短事务、统一操作顺序、索引优化及异常重试。
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逻辑分析原因，再通过优化事务结构和索引来降低风险。
