mysql死锁是多事务并发执行时因相互等待资源而形成的僵局，常见原因包括互斥、持有并等待、不可抢占和循环等待。例如事务a和b交叉更新不同表导致互相等待。排查方式主要有：1.使用show engine innodb status查看最近死锁详情；2.检查错误日志获取事务sql、锁类型等信息。避免死锁的方法有：1.统一访问顺序；2.减少事务粒度；3.批量合并更新；4.保持加锁顺序一致；5.使用乐观锁；6.引入重试机制。若已发生死锁，应分析日志、优化sql与索引、缩短事务长度，甚至重构业务逻辑，从而降低死锁概率，保障系统稳定性。
MySQL死锁是多事务并发执行时，彼此持有部分资源又相互等待对方释放资源，导致谁也无法继续推进的一种僵局。这种现象虽然不常出现，但一旦发生会影响系统性能甚至服务可用性。要有效避免和解决死锁问题，得先理解它的成因，并掌握一些实用的排查与优化手段。
一、死锁产生的常见原因
死锁通常由以下四个条件共同作用而形成：
- 互斥：资源不能共享，一次只能被一个事务占用。
- 持有并等待：事务在等待其他资源的同时，不释放已持有的资源。
- 不可抢占：资源只能由持有它的事务主动释放。
- 循环等待：存在一个事务链，每个事务都在等待下一个事务所持有的资源。
举个简单例子：事务 A 更新了表 t1 的某条记录，接着试图更新表 t2；与此同时，事务 B 先更新了 t2，又想更新 t1。这时，A 等着 B 释放 t2 的锁，B 又等着 A 释放 t1 的锁，就形成了死锁。
二、如何查看和定位死锁？
MySQL 的 InnoDB 引擎会在检测到死锁后自动回滚其中一个事务，并将相关信息记录到日志中。你可以通过以下方式查看死锁信息：
- 使用命令
SHOW ENGINE INNODB STATUS\G
，输出结果中的 LATEST DETECTED DEADLOCK 部分会显示最近一次死锁的详细情况。 - 检查 MySQL 错误日志，里面也会记录事务的回滚信息。
这部分信息包括：
- 涉及的事务 ID
- 各自执行的 SQL 语句
- 请求的锁类型和等待的资源
这些信息对分析死锁根源非常关键，建议开发或 DBA 在遇到死锁后第一时间查看。
三、避免死锁的几种常用方法
为了避免死锁，核心思路是打破上面提到的四个必要条件之一，尤其是“循环等待”这个点。以下是几个实用做法：
- 统一访问顺序：多个事务操作多个表时，尽量按照相同的顺序来访问（比如都先操作 t1 再操作 t2）。
- 减少事务粒度：事务尽量短小精悍，不要在一个事务里做太多操作，尽早提交。
- 批量更新合并：能用一条 SQL 完成的更新，就不要拆分成多个语句。
- 加锁顺序一致：即使是在同一张表的不同行上，也要注意加锁顺序是否一致。
- 使用乐观锁机制：在业务层尝试更新前检查版本号，避免数据库层面的冲突。
另外，在写业务逻辑的时候，可以考虑引入重试机制，当捕获到死锁异常（如 Deadlock found when trying to get lock）时，自动重试事务。
四、死锁已经发生了怎么办？
如果线上环境出现了死锁，首先别慌，InnoDB 一般会自动处理掉一个事务，另一个则能正常完成。但这只是“临时救火”，要彻底解决问题还得靠后续分析：
- 分析死锁日志，看事务之间的执行顺序和涉及的数据。
- 检查是否有全表扫描或未使用索引的情况，这会导致锁定过多行。
- 查看事务是否太长或 SQL 是否复杂，尝试优化。
- 如果频繁出现，可能需要重构业务逻辑或者调整表结构设计。
有时候，死锁的发生是因为索引选择不当，比如更新语句没有命中合适的索引，导致锁住大量无关数据。这种情况下，添加合适索引或修改查询条件，往往能显著减少死锁概率。
基本上就这些。死锁不是大问题，但也别忽视它。只要平时注意代码规范、SQL 编写顺序以及事务控制，大多数死锁是可以规避的。
