mysql 死锁案例及分析过程
我将分别从以下几个方面进行讲解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,即锁住索引本身,而不是范围)
比较懒,上图(分享过的图)