死锁的发生必须具备以下四个必要条件
- 互斥条件（Mutual exclusion）：资源不能被共享，只能由一个进程使用。
- 请求与保持条件（Hold and wait）：已经得到资源的进程可以再次申请新的资源。
- 不可剥夺条件（No pre-emption）：已经分配的资源不能从相应的进程中被强制地剥夺。
- 环路/循环等待条件（Circular wait）：系统中若干进程组成环路，该环路中每个进程都在等待相邻进程正占用的资源。
解决死锁有俩种策略，一种事先预防，一种是事后解除死锁
预防死锁
通过破坏四个必要条件中的一个或多个，使死锁永远无法满足。实现简单，但是由于所施加的限制条件往往太严格，可能会导致系统资源利用率和系统吞吐量降低。
预先资源分配法
一次性申请所有需要的资源，只要有一种资源不满足要求，哪怕其它需要的资源都足够，也不做任何分配。这样一来就没有“保持”资源的状态，只有“请求”资源的状态，破坏了请求与保持条件。
有序资源分配法
在申请不同类资源时，必须按指定顺序申请，破坏了环路等待条件。
正例：线程A、B申请资源顺序均为R1->R2；
反例：A申请顺序为R1->R2，B申请顺序为R2->R1。
避免死锁
也是预发死锁，但不会事先去破坏死锁的必要条件，只是有人请求资源时，用某种方法防止系统进入不安全的状态（死锁），从而避免发生死锁。
比如银行家算法：基本思想是分配资源之前，判断系统是否是安全的；若是，才分配。
检测死锁和解除
不采取措施防止死锁产生，允许系统产生死锁，但是可以通过一些手段检测出死锁，然后将死锁解除。
检测方法：
- 定时检测
- 效率低时检测
- 进程等待时检测
mysql采取的策略及时就是第二种，当不同的事务以不同的顺序获取某些记录的锁时 可能会发生死
锁.当死锁发生时InnoDB会因滚单个事务以释放掉该事务所获取的锁。
我们有必要找出那些发生死锁的语句，通过优化语句来改变加锁顺序 或者建立合适的索引以改变加锁过程，从而避免死锁问题。不过，在实际应用中我们可能压根儿不知道到底是哪些语句在执行时导致了死锁，因此需要根据死锁发生时产生的死锁日志来逆向定位产生死锁的语句，然后再优化我们的业务。
可以通过执行SHOW ENGINE INNODB STATUS语句来查看最近发生的一次死锁信息。
通过以上日志可以分析死锁产生的原因，通过对业务代码的更改，可以解除死锁，从而提高执行效率。