我将分别从以下几个方面进行讲解mysql 死锁 的每一个案例，希望能够对你们有帮忙及启发
-
pre --- 预备知识（可直接跳过，建议耐着性子看完）
-
锁类型
-
一致性非锁定读
-
一致性锁定读
-
行锁的三种算法
-
-
start --- 正式开始
-
死锁的条件
-
死锁分析
-
死锁示例
-
pre
一、锁类型 innodb存储引擎实现了如下两种标准的行级锁（多粒度锁定之意向锁自行了解，此处抛出而已）
-
-
共享锁（S Lock），允许事务读一行数据。
-
排他锁（X Lock），允许事务删除或更新一行数据
-
二、一致性非锁定读
一致性的非锁定读是指InnoDB存储引擎通过行多版本控制（MVCC自行了解）的方式来读取当前执行时间数据库中行的数据，而不需要等待访问的行上X锁的释放。（在InnoDB存储引擎的默认设置下，这是默认的读取方式）
PS：1.该技术不会有额外的开销，因为读取的快照数据其实是行数据之前的版本数据，该实现是通过undo （undo log 事务回滚 自行了解）段来完成。
2.不同的事务隔离级别下，读取的方式不同（并不是在每个事务隔离级别下都是采用非锁定的一致性读，自行思考，tip：脏读，不可重复读，幻读）
三、一致性锁定读
-
-
SELECT...FOR UPDATE 对读取的行记录加一个X锁，其他事务不能对已锁定的行加上任何锁
-
SELECT...LOCK IN SHARE MODE 对读取的行记录加一个S锁，其他事务可以向被锁定的行加S锁，但如果加X锁，则会被阻塞
-
(PS:以上要想使用必须在事务中，当事务提交了，锁也就释放了)
四、行锁的三种算法
-
-
Record Lock: 单个行记录上的锁
-
Gap Lock: 间隙锁，锁定一个范围，但不包含记录本身
-
Next-Key Lock: Gap Lock + Record Lock，锁定一个范围，并且锁定记录本身 (可解决 Phantom Problem)
-
(PS:当查询的索引含有唯一属性时，InnoDB存储引擎会对Next-Key Lock进行优化，将其降级为Record Lock，即锁住索引本身，而不是范围)
比较懒，上图（分享过的图）
