MySQL（6）LOCK和MVCC

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

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

三、MySQL中锁的应用

(1)insert
插入意向锁
隐式锁，当产生竞争的情况下会生成行锁，比如多个插入操作
自增锁，autoinc锁，是主键自增的时候，保证主键自增安全性，有三个策略 0 1 2，默认1,0=insert操作完成后释放，2，insert操作开始前释放，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）和已创建的最大事务id（max_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申请真正的事务id，mysql内部是严格按照事务的启动顺序来分
配事务id的。
(8)事务结束不一定都清除版本链，insert 会清除，update如果有依赖不能清除

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

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