mysql中的各类锁把我搞糊涂啦~

你们好， 我是公众号：java小杰要加油，
今天来分享一个关于mysql的知识点—— mysql中的锁

• 话很少说，直接开车

事务并发访问状况

读-读 状况

• 并发事务读取相同的数据，并不会对数据形成影响，容许并发读

写-写 状况

• 多事务并发写写时会发生脏写的状况，不过任何一个事务隔离级别都不容许此状况发生，经过加锁来杜绝脏写

脏写

• 事务T1 将数据改为了A,可是还未提交，可此时事务T2又将数据改为了B，覆盖了事务T1的更改，T1更新丢失，这种状况叫作脏写

加锁

• 例如，如今事务T1,T2对这条记录进行并发更改，刚才说是隔离级别是经过加锁来杜绝此脏写的，流程以下

这个锁结构中有两个比较关键的信息（其实还有不少信息，后面再聊）

• trx信息：表示这个锁结构是和哪一个事务所关联的
• is_waiting信息：表示当前事务是否正在等待

Q： 能描述一下两个事务并发修改同一条数据时，mysql这个锁是怎么避免脏写的吗？

A ：事务T1在更改这条数据前，就先内存中生成一把锁与此数据相关联（is_waiting为false,表明没有等待），而后咔咔一顿操做更改数据，这个时候，事务T2来了，发现此记录已经有一把锁与之相关联了（就是T1那一把锁），而后就开始等待（is_waiting为true表明正在等待），事务T1更改完数据提交事务后，就会把此事务对应的所结构释放掉，而后检测一下还有没有与此记录相关联的锁，结果发现T2还在苦苦的等待，就把T2的锁结构的（is_waiting为false,表明没有等待）而后把T2事务对应的线程唤醒，T2获取锁成功继续执行，整体流程如上。

读-写 /写-读 状况

在读-写 / 写 -读的状况下会出现脏读，不可重复读，幻读的现象，不一样的隔离级别能够避免不一样的问题，具体相关内容能够看小杰的这篇文章 京东面试官问我：“聊聊MySql事务,MVCC？”

不过贴心的我仍是列出来了 注：√表明可能发生，×表明不可能发生

隔离级别	脏读	不可重复读	幻读
读未提交（read uncommitted RU）	√	√	√
读提交（read committed RC）	×	√	√
可重复读（repeatable read RR）	×	×	√
串行化（serializable ）	×	×	×

可是 RR在某些程度上避免了幻读的发生

怎么避免脏读、不可重复读、幻读这些现象呢？其实有两种方案

• 方案一 ：读操做使用MVCC，写操做进行加锁

• mvcc里面最重要的莫过于ReadView了，它的存在保证了事务不能够读取到未提交的事务所做的更改，避免了脏读。
• 在RC隔离级别下，每次select读操做都会生成ReadView
• 在RR隔离级别下，只有第一次select读操做才会生成ReadView，以后的select读操做都复用这一个ReadView

• 方案二：读写操做都用加锁

某些业务场景不容许读取旧记录的值，每次读取都要读取最新的值。
例如银行取款事务中，先把余额读取出来，再对余额进行操做。当这个事务在读取余额时，不容许其余事务对此余额进行访问读取，直到取款事务结束后才能够访问余额。因此在读数据的时候也要加锁

锁分类

当使用 读写都加锁这个方案来避免并发事务 写-写、 读-写、 写-读时而产生的 脏读， 不可重复读， 幻读现象时，那么这个锁它就要作到，读读时不相互影响，上面三种状况时要相互阻塞，这时锁也分了好几类，咱们继续往下看

锁定读

• 共享锁（Shared Lock）：简称S锁，在事务要读取一条记录时，须要先获取该记录的S锁
• 独占锁（Exclusive Lock）：简称X锁，也称排他锁，在事务要改动一条记录时，须要先获取该记录的X锁

他们之间兼容关系以下 √表明能够兼容，×表明不可兼容

兼容性	S锁	X锁
S锁	√	×
X锁	×	×

事务T1获取某记录的S锁后，

• 事务T2也能够获取此记录的S锁，(兼容)
• 事务T2不能够获取此记录的X锁，直到T1提交后将S锁释放 (不兼容)

事务T1获取某记录的X锁后，

• 事务T2不能够获取此记录的S锁，直到T1提交后将X锁释放 (不兼容)
• 事务T2不能够获取此记录的X锁，直到T1提交后将X锁释放 (不兼容)

锁定读语句

SELECT .. LOCK IN SHARE MODE   # 对读取的记录添加S锁

SELECT .. FOR UPDATE # 对读取的记录添加X锁

多粒度锁

前面提到的锁都是针对记录的，其实一个事务也能够在表级进行加锁（S锁、X锁）

• T1给表加了S锁，那么

  • T2能够继续获取此表的S锁
  • T2能够继续获取此表中的某些记录的S锁
  • T2不能够继续获取此表的X锁
  • T2不能够继续获取此表中的某些记录的X锁

• T1给表加了X锁，那么

  • T2不能够继续获取此表的S锁
  • T2不能够继续获取此表中的某些记录的S锁
  • T2不能够继续获取此表的X锁
  • T2不能够继续获取此表中的某些记录的X锁

但是怎么可能无缘无故的就给表加锁呢，难道没什么条件吗？答案是确定有条件的

• 若想给表加S锁，得先确保表中记录没有X锁
• 若想给表加X锁，得先确保表中记录没有X锁和S锁

可是这个怎么确保呢？难道要一行一行的遍历表中的全部数据吗？固然不是啦，聪明的大佬们想出了下面这两把锁

• 意向共享锁（Intention Shared Lock）:简称IS锁，当事务准备在某记录上加S锁时，须要先在表级别加上一个IS锁
• 意向独占锁（Intention Exclusive Lock）:简称IX锁，当事务准备在某记录上加X锁时，须要先在表级别加上一个IX锁

让咱们来看下加上这两把锁以后的效果是什么样子的

• 当想给记录加S锁时，先给表加一个IS锁，而后再给记录加S锁

• 当想给记录加X锁时，先给表加IX锁，而后再给记录加X锁

而后 通过上面的操做以后

• 若是想给表加S锁，先看下表加没加IX锁，若是有的话，则代表此表中的记录有X锁，则须要等到IX锁释放掉后才能够加S锁

• 若是想给表加X锁，先看下表加没加IS锁或者IX锁，若是有的话，则代表此表中的记录有S锁或者X锁，则须要等到IS锁或者IX锁释放掉后才能够加X锁

这几种锁的兼容性以下表

兼容性	IS锁(表级锁)	S锁	IX锁(表级锁)	X锁
IS锁(表级锁)	√	√	√	×
S锁	√	√	×	×
IX锁(表级锁)	√	×	√	×
X锁	×	×	×	×

• IS、IX锁都是表级锁，他们能够共存。
• 他们的提出仅仅是为了在以后加表级别的S锁或者X锁时能够快速判断表中的记录是否被上锁，避免用遍历的方式来查看一行一行的去查看而已

InnoDB中的行级锁

Record Lock（记录锁）

• 官方名字 LOCK_REC_NOT_GAP
• 仅仅锁住一条记录
• 有S型和X型之分

Gap Lock（间隙锁）

• 官方名字 LOCK_GAP
• 给某记录加此锁后，阻塞数据在此记录和上一个记录的间隙插入，可是不锁定此记录
• 有S型和X型之分，但是并无什么区别他们的做用是相同的，gap锁的做用仅仅是为了防止插入幻影记录而已，若是对一条记录加了gap锁（不管S/X型）并不会限制其余事务对这条记录加Record Lock或者Gap Lock

Next-Key Lock(记录锁+间隙锁)

• 官方名字 LOCK_ORDINARY
• 既能够锁住某条记录，又能够组织其余事务在该记录面前插入新记录

Insert Intention Lock(插入意向锁锁)

• 官方名字 LOCK_INSERT_INTENTION
• 事务在插入记录时，若是插入的地方加了gap锁，那么此事务须要等待，此时此事务在等待时也须要生成一个锁结构，就是插入意向锁

锁内存结构

• 咱们难道锁一条记录就要生成一个锁结构吗？

固然不是！

一个锁结构

若是被加锁的记录符合下面四条状态的话，那么这些记录的锁则会合到一个锁结构中

• 在同一个事务中进行加锁操做
• 被加锁的记录在同一个页面中
• 加锁的类型是同样的
• 等待的状态是同样的

锁结构信息

而后咱们再来依此看下这个所结构每一个部分的信息都是什么意思

• 锁所在的事务信息：不管是表级锁仍是行级锁，一个锁属于一个事务，这里记载着该锁对应的信息
• 索引信息：对于行级锁来讲，须要记录一下加锁的记录属于哪一个索引

• 表锁/行锁信息：行级锁

  • Space_ID：记录所在的表空间

  * Page Number：记录所在的页号

  • n_bits：一条记录对应着一个比特；一个页面包含多条记录，用不一样的比特来区分究竟是那一条记录加了锁,有个计算公式以下（公式中是取商）n_bits = （1+（n_recs+LOCK_PAGE_BITMAP_MARGIN）/ 8）x 8LOCK_PAGE_BITMAP_MARGIN是固定的值为64，n_recs指当前界面一共有多少条记录（包含伪记录以及在垃圾链表中的记录），
• type_mode：32比特的数

• lock_mode（锁模式）：低4比特位表示

  • LOCK_AUTO_INC(十进制的4)：表示AUTO-INC锁
  • LOCK_IS(十进制的0)：表示共享意向锁，IS锁
  • LOCK_IX(十进制的1)：表示独占意向锁，IX锁
  • LOCK_S(十进制的2)：表示共享锁，也就是S锁
  • LOCK_X(十进制的3)：表示独占锁，也就是X锁

• lock_type（锁类型）：第5~8比特位表示

  • LOCK_TABLE(十进制的1)：当第5比特位设置为1时，表示表级锁
  • LOCK_REC(十进制的32)：当第6比特位设置为1时，表示行级锁

• rec_lock_type（行锁的具体类型）：其他的比特位表示

  • LOCK_ORDINARY(十进制的0)：表示next-key锁
  • LOCK_GAP(十进制的512)：当第10比特位是1时，表示gap锁
  • LOCK_REC_NOT_GAP(十进制的1024)：也就是当第11比特设置为1时，表示Record Lock(记录锁)
  • LOCK_INSERT_INTENTION(十进制的2048)：也就是当第12比特设置为1时，表示Insert Intention Lock（插入意向锁）

  • LOCK_WAIT(十进制的256)：也就是当

    • 第9比特设置为1时，表示is_waiting为true,即当前事务获取锁失败，处于等待状态
    • 第9比特设置为0时，表示is_waiting为false,即当前事务获取锁成功

• 其余信息：此文章不讨论
• 一堆比特位：此文章不讨论

举个例子

事务T1 要给user表中的记录加锁，假设这些记录存储在表空间号为20，页号为21的页面上，T1给id=1的记录加S型Record Lock锁，假如当前页面一共有5条记录（3条用户记录和2条伪记录）

过程：先给表加IS锁，不过咱们如今不关心，只关心行级锁，
具体生成的所结构以下图所示

最后

• 快过年啦，小杰可能也须要休息一下下，由于最近都周更（虽然上周有点事没更，打脸），周末彻底没有其他时间了
• 感受和朋友家人们联系有点少了，过年回家巩固下感情和朋友们聊聊天吹吹牛逼，顺便维护下峡谷的治安
• 最后祝关注java小杰要加油的宝贝儿们
• 脱单暴富事事顺，升职加薪牛哄哄！

好文推荐

• 五千来字小做文，是的，咱们是有个HTTP。
• 同窗，二叉树的各类遍历方式，我都帮你总结了，附有队列堆栈图解（巩固基础，强烈建议收藏）
• 京东面试官问我：“聊聊MySql事务,MVCC？（好文，建议收藏）”
• 你好，我叫AQS（系列一：加锁）
• 京东这道面试题你会吗？
• ？线程池为何能够复用，我是蒙圈了。。。