MySQL相关（九）- 死锁的发生和避免
前言
在上一篇章我们讲了行级锁的原理，大家看到这里的话应该也了解得差不多了，我们这里再来讲讲通过对行级锁的认识学习之后，应该注意和避免的点。
在我们使用锁的时候，有一个问题是需要注意和避免的，我们知道，排它锁有互斥的特性。一个事务或者说一个线程持有锁的时候，会阻止其他的线程获取锁，这个时候会造成阻塞等待，如果循环等待，会有可能造成死锁。
这个问题我们需要从几个方面来分析，一个是锁为什么不释放，第二个是被阻塞了怎么办，第三个死锁是怎么发生的，怎么避免。我们且看正文部分。
老规矩，先上飞机票：
- MySQL相关（一）- 一条查询语句是如何执行的
- MySQL相关（二）- 一条更新语句是如何执行的
- MySQL相关（番外篇）- innodb 逻辑存储结构；
- MySQL相关（三）- 索引数据模型推演及 B+Tree 的详细介绍；
- MySQL相关（四）- 性能优化关键点索引
- MySQL相关（五）- 事务特性及隔离级别的详细介绍
- MySQL相关（六）- 事务隔离级别的实现方案（MVCC）
- MySQL相关（七）- innodb 锁的介绍及使用
- MySQL相关（八）- innodb行级锁深入剖析
前面提到的脑图如下，想要完整高清图片可以到微信我的公众号下【6曦轩】下回复 MySQL 脑图获取：
正文
死锁
锁的释放与阻塞
回顾：锁什么时候释放？
事务结束（commit，rollback）；客户端连接断开。
如果一个事务一直未释放锁，其他事务会被阻塞多久？会不会永远等待下去？如果是，在并发访问比较高的情况下，如果大量事务因无法立即获得所需的锁而挂起，会占用大量计算机资源，造成严重性能问题，甚至拖跨数据库。
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction MySQL 有一个参数来控制获取锁的等待时间，默认是 50 秒。
show VARIABLES like 'innodb_lock_wait_timeout';
对于死锁，是无论等多久都不能获取到锁的，这种情况，也需要等待 50 秒钟吗？那
不是白白浪费了 50 秒钟的时间吗？
我们先来看一下什么时候会发生死锁。
死锁的发生和检测
死锁演示：
| Session 1 | Session 2 |
|---|---|
| begin; select * from t2 where id =1 for update; |
|
| - | begin; delete from t2 where id =4 ; |
| update t2 set name= ‘4d’ where id =4 ; | |
| - | delete from t2 where id =1 ; |
在第一个事务中，检测到了死锁，马上退出了，第二个事务获得了锁，不需要等待 50 秒：
[Err] 1213 - Deadlock found when trying to get lock; try restarting transaction
为什么可以直接检测到呢？是因为死锁的发生需要满足一定的条件，所以在发生死锁时，InnoDB 一般都能通过算法（wait-for graph）自动检测到。
那么死锁需要满足什么条件？死锁的产生条件：
因为锁本身是互斥的
（1）同一时刻只能有一个事务持有这把锁；
（2）其他的事务需要在这个事务释放锁之后才能获取锁，而不可以强行剥夺；
（3）当多个事务形成等待环路的时候，即发生死锁。
举例：
理发店有两个总监。一个负责剪头的 Tony 总监，一个负责洗头的 Kelvin 总监。
Tony 不能同时给两个人剪头，这个就叫互斥。
Tony 在给别人在剪头的时候，你不能让他停下来帮你剪头，这个叫不能强行剥夺。如果 Tony 的客户对 Kelvin 总监说：你不帮我洗头我怎么剪头？Kelvin 的客户对 Tony 总监说：你不帮我剪头我怎么洗头？这个就叫形成等待环路。
如果锁一直没有释放，就有可能造成大量阻塞或者发生死锁，造成系统吞吐量下降，这时候就要查看是哪些事务持有了锁。
查看锁信息（日志）
SHOW STATUS 命令中，包括了一些行锁的信息：
show status like 'innodb_row_lock_%';
- Innodb_row_lock_current_waits：当前正在等待锁定的数量；
- Innodb_row_lock_time ：从系统启动到现在锁定的总时间长度，单位 ms；
- Innodb_row_lock_time_avg ：每次等待所花平均时间；
- Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花的时间；
- Innodb_row_lock_waits ：从系统启动到现在总共等待的次数。
SHOW 命令是一个概要信息。InnoDB 还提供了三张表来分析事务与锁的情况：
select * from information_schema.INNODB_TRX; -- 当前运行的所有事务 ，还有具体的语句
select * from information_schema.INNODB_LOCKS; -- 当前出现的锁
select * from information_schema.INNODB_LOCK_WAITS; -- 锁等待的对应关系
找出持有锁的事务之后呢？
如果一个事务长时间持有锁不释放，可以 kill 事务对应的线程 ID ，也就是 INNODB_TRX 表中的 trx_mysql_thread_id，例如执行 kill 4，kill 7，kill 8。
当然，死锁的问题不能每次都靠 kill 线程来解决，这是治标不治本的行为。我们应该尽量在应用端，也就是在编码的过程中避免。
有哪些可以避免死锁的方法呢？
死锁的避免
- 在程序中，操作多张表时，尽量以相同的顺序来访问（避免形成等待环路）；
- 批量操作单张表数据的时候，先对数据进行排序（避免形成等待环路）；
- 申请足够级别的锁，如果要操作数据，就申请排它锁；
- 尽量使用索引访问数据，避免没有 where 条件的操作，避免锁表；
- 如果可以，大事务化成小事务；
- 使用等值查询而不是范围查询查询数据，命中记录，避免间隙锁对并发的影响。
By the way
有问题？可以给我留言或私聊
有收获？那就顺手点个赞呗~
当然，也可以到我的公众号下「6曦轩」，
回复“学习”，即可领取一份
【Java工程师进阶架构师的视频教程】~
回复“面试”，可以获得：
【本人呕心沥血整理的 Java 面试题】
回复“MySQL脑图”，可以获得
【MySQL 知识点梳理高清脑图】
由于我咧，科班出身的程序员，php，Android以及硬件方面都做过，不过最后还是选择专注于做 Java，所以有啥问题可以到公众号提问讨论（技术情感倾诉都可以哈哈哈），看到的话会尽快回复，希望可以跟大家共同学习进步，关于服务端架构，Java 核心知识解析，职业生涯，面试总结等文章会不定期坚持推送输出，欢迎大家关注~~~
