mysql 死锁案例及分析过程

我将分别从以下几个方面进行讲解mysql 死锁 的每一个案例，希望能够对你们有帮忙及启发

• pre   ---   预备知识（可直接跳过，建议耐着性子看完）

• 锁类型

• 一致性非锁定读

• 一致性锁定读

• 行锁的三种算法

• start　　---   正式开始

• 死锁的条件

• 死锁分析

• 死锁示例

pre

一、锁类型  innodb存储引擎实现了如下两种标准的行级锁（多粒度锁定之意向锁自行了解，此处抛出而已）

1. 1. 共享锁（S Lock），允许事务读一行数据。

   2. 排他锁（X Lock），允许事务删除或更新一行数据

　   二、一致性非锁定读

　　一致性的非锁定读是指InnoDB存储引擎通过行多版本控制（MVCC自行了解）的方式来读取当前执行时间数据库中行的数据，而不需要等待访问的行上X锁的释放。（在InnoDB存储引擎的默认设置下，这是默认的读取方式）

PS：1.该技术不会有额外的开销，因为读取的快照数据其实是行数据之前的版本数据，该实现是通过undo （undo log 事务回滚  自行了解）段来完成。

　　2.不同的事务隔离级别下，读取的方式不同（并不是在每个事务隔离级别下都是采用非锁定的一致性读，自行思考，tip：脏读，不可重复读，幻读）

三、一致性锁定读

1. 1. SELECT...FOR UPDATE 对读取的行记录加一个X锁，其他事务不能对已锁定的行加上任何锁

   2. SELECT...LOCK IN SHARE MODE 对读取的行记录加一个S锁，其他事务可以向被锁定的行加S锁，但如果加X锁，则会被阻塞

(PS:以上要想使用必须在事务中，当事务提交了，锁也就释放了)

四、行锁的三种算法

1. 1. Record Lock: 单个行记录上的锁

   2. Gap Lock: 间隙锁，锁定一个范围，但不包含记录本身

   3. Next-Key Lock: Gap Lock + Record Lock，锁定一个范围，并且锁定记录本身 (可解决 Phantom Problem)

(PS:当查询的索引含有唯一属性时，InnoDB存储引擎会对Next-Key Lock进行优化，将其降级为Record Lock，即锁住索引本身，而不是范围)

比较懒，上图（分享过的图）