MySQL（6）LOCK和MVCC-CSDN博客

一、锁的分类
按照锁的属性读锁、写锁、共享锁、排它锁、悲观锁、乐观锁
按照锁的范围表锁、页锁、间隙锁、临键锁、行锁
按照锁的作用意向锁、意向共享锁、意向排它锁、IS锁、IX锁

二、MySQL为什么要有锁
锁是计算机协调多个进程或线程并发访问某一资源的机制。
在数据库中除了传统的计算资源如CPU、RAM、I/O等的争用以外数据也是一种供需要用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题锁冲突也是影响数据库并发访问性能的一个重要因素。
MySQL中锁是为了解决事务并发下数据库不同隔离级别出现的问题 脏读 不可重复读 幻读

三、MySQL中锁的应用

(1)insert
插入意向锁
隐式锁当产生竞争的情况下会生成行锁比如多个插入操作
自增锁autoinc锁是主键自增的时候保证主键自增安全性有三个策略 0 1 2默认1,0=insert操作完成后释放2insert操作开始前释放1由mysql自主决定

(2)update
next-key锁
三种情况
where条件是主键获唯一索引==转化为行锁范围 next-key ==记录不存在 next-key
where条件是普通索引next-key
where条件不是索引表锁

(3)delete 和update基本相同

(4)select
默认不加锁但是在串行化隔离级别默认加共享锁
如果有 for update 排它锁(也不一定)
如果是 lock in share mode 共享锁 

四、MySQL中锁的互斥情况
共享锁和共享锁不互斥
共享锁和独占锁互斥
意向锁之间不排斥意向锁包括共享和独占独占和独占也不排斥
间隙锁和间隙锁之间不互斥
临键锁和临键锁视情况因为有行锁如果行锁冲突就互斥

五、锁的用法
for update  排它锁
lock in share mode  共享锁
lock table user read/write  表锁
unlock tables  解除表锁
show engine innodb status; 查询锁情况

通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况
show status like 'innodb_row_lock%';

对各个状态量的说明如下
Innodb_row_lock_current_waits: 当前正在等待锁定的数量
Innodb_row_lock_time: 从系统启动到现在锁定总时间长度
Innodb_row_lock_time_avg: 每次等待所花平均时间
Innodb_row_lock_time_max从系统启动到现在等待最长的一次所花时间
Innodb_row_lock_waits: 系统启动后到现在总共等待的次数

对于这5个状态变量比较重要的主要是
Innodb_row_lock_time_avg 等待平均时长
Innodb_row_lock_waits 等待总次数
Innodb_row_lock_time等待总时长

六、锁优化实践
尽可能让所有数据检索都通过索引来完成避免无索引行锁升级为表锁
合理设计索引尽量缩小锁的范围
尽可能减少检索条件范围避免间隙锁
尽量控制事务大小减少锁定资源量和时间长度涉及事务加锁的sql尽量放在事务最后执行
尽可能用低的事务隔离级别

七、问题
select for update 加的一定是排它锁吗
不能简单地说 select … for update 加的是共享锁还是排他锁 
如果select有结果则加行锁此时为排他锁 
如果没有结果,则加间隙锁此时为共享锁和间隙大小没有关系 
如果没有在事务中则select for update是不加锁的

八、undo日志版本链与read view机制详解
undo日志版本链是指一行数据(注意是一行数据)被多个事务依次修改过后在每个事务修改完后Mysql会保留修改前的数据undo回滚日志并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链

在可重复读隔离级别当事务开启执行任何查询sql时会生成当前事务的一致性视图read-view该视图在事务结束之前永远都不会变化(如果是读已提交隔离级别在每次执行查询sql时都会重新生成read-view)这个视图由执行查询时所有未提交事务id数组数组里最小的id为min_id和已创建的最大事务idmax_id组成事务里的任何sql查询结果需要从对应版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果

版本链比对规则
1. 如果 row 的 trx_id 落在绿色部分( trx_id<min_id )表示这个版本是已提交的事务生成的这个数据是可见的
2. 如果 row 的 trx_id 落在红色部分( trx_id>max_id )表示这个版本是由将来启动的事务生成的是不可见的(若 row 的trx_id 就是当前自己的事务是可见的
3. 如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)那就包括两种情况
a. 若 row 的 trx_id 在视图数组中表示这个版本是由还没提交的事务生成的不可见(若 row 的 trx_id 就是当前自己的事务是可见的)
b. 若 row 的 trx_id 不在视图数组中表示这个版本是已经提交了的事务生成的可见。

对于删除的情况可以认为是update的特殊情况会将版本链上最新的数据复制一份然后将trx_id修改成删除操作的trx_id同时在该条记录的头信息record header里的deleted_flag标记位写上true来表示当前记录已经被删除在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true意味着记录已被删除则不返回数据

关于readview和可见性算法的原理解释
readview和可见性算法其实就是记录了sql查询那个时刻数据库里提交和未提交所有事务的状态。
要实现RR隔离级别事务里每次执行查询操作readview都是使用第一次查询时生成的readview也就是都是以第一次查询时当时数据库里所有事务提交状态来比对数据是否可见当然可以实现每次查询的可重复读的效果了。
要实现RC隔离级别事务里每次执行查询操作readview都会按照数据库当前状态重新生成readview也就是每次查询都是跟数据库里当前所有事务提交状态来比对数据是否可见当然实现的就是每次都能查到已提交的最新数据效果了。

九、可重复读隔离级别下解决幻读
mvcc 机制和临键锁
如果是快照读事务开始的时候有一个readview在这个事务中都读的readview的版本
如果是当前读使用锁机制临键锁和update  insert delete 操作是互斥的但是没有彻底解决如果一个事务是有快照读和当前读之间有操作就有可能出现读取不一致的情况
比如
begin;
select * from tbl_user where id >1;
update tbl_user  set age = 3313 where id = 18;
select * from tbl_user where id >1 ;
COMMIT;
这样如果更新的操作是另一个事务插入的数据第二次查询就能查询到比第一次查询多一条记录产生幻读解决就是第一次也当前读加上for update 

十、总结
MVCC机制的实现就是通过read-view机制与undo版本链比对机制使得不同的事务会根据数据版本链对比规则读取同一条数据在版本链上的不同版本数据。

十一、扩展点
(1)update 操作扩展点
如果是主键更新不更新主键如果更新的大小不变就地更新如果大小改变先delete再insert、如果更新主键先delete再insert
扩展简单的insert会在insert的行对应的索引记录上加一个排它锁这是一个record lock并没有gap所以并不会阻塞其他session在gap间隙里插入记录。
不过在insert操作之前还会加一种锁官方文档称它为insertion intention gap lock也就是意向的gap锁。
这个意向gap锁的作用就是预示着当多事务并发插入相同的gap空隙时只要插入的记录不是gap间隙中的相同位置则无需等待其他session就可完成这样就使得insert操作无须加真正的gap lock。
(2)间隙锁只有在RR级别InnoDB的行锁实际上是针对索引加的锁(在索引对应的索引项上做标记)不是针对整个行记录加的锁。并且该索引不能失效否则会从行锁升级为表锁。(RR级别会升级为表锁RC级别不会升级为表锁)
(3)因为在RR隔离级别下需要解决不可重复读和幻读问题所以在遍历扫描聚集索引记录时为了防止扫描过
的索引被其它事务修改(不可重复读问题) 或 间隙被其它事务插入记录(幻读问题)从而导致数据不一致所以MySQL的解决方案就是把所有扫描过的索引记录和间隙都锁上
(4)间隙锁锁的就是两个值之间的空隙间隙锁是在可重复读隔离级别下才会生效。
(5)MyISAM在执行查询语句SELECT前会自动给涉及的所有表加读锁在执行update、insert、delete操作会自动给涉及的表加写锁。
(6)InnoDB在执行查询语句SELECT时(非串行隔离级别)不会加锁。但是update、insert、delete操作会加行锁。
(7)begin/start transaction 命令并不是一个事务的起点在执行到它们之后的第一个修改操作或加排它锁操作(比如select...for update)的语句事务才真正启动才会向mysql申请真正的事务idmysql内部是严格按照事务的启动顺序来分配事务id的。
(8)事务结束不一定都清除版本链insert 会清除update如果有依赖不能清除

(9)Spring标注了@Transactional的方法不是方法一开始都开启事务是在第一个update操作或者for update 操作开始才开启事务
一般我们在MySQL客户端执行 begin 开启事务不等价与带有@Transactional方法的开始而是第一个update操作或者for update 操作开始
(10)如果没有 @TransactionalMySQL不开启事务执行不加锁

(11)间隙锁是共存的间隙锁和插入意向锁是排斥的插入意向锁和插入意向锁是排斥的如果多个事务同时获取间隙锁其中一个事务释放了插入意向锁其他事务都抢插入意向锁而插入意向锁又和间隙锁是互斥的所有事务都想获取插入意向锁但是都不放弃间隙锁就导致死锁

(12)update 操作的时候如果是主键更新不更新主键如果更新的大小不变就地更新如果大小改变先delete再insert

如果更新主键先delete再insert