一文详解MySQL各种锁及MVCC的使用场景及原理

普通的 select 语句是不会对记录加锁的，因为它属于快照读。
如果要在查询时对记录加行锁，则为锁定读,方式为:
- select ... lock in share mode;//对读取的记录加共享锁
- select ... for update;//对读取的记录加独占锁

共享锁（S锁）满足读读共享，读写互斥。独占锁（X锁）满足写写互斥、读写互斥

在开启事务的情况下，查询使用FOR UPDATE，如果使用了索引/主键并且索引生效的情况下，是行锁，否则是表锁。

记录锁(Record Lock)

作用于一条记录,只能锁住已经存在的记录，为了避免插入新记录，需要依赖间隙锁。

间隙锁(Gap Lock)

锁定一个范围(左开右开)，但是不包含记录本身

临键锁(Next-Key Lock)

Record Lock+Gap Lock ,锁定一个范围(左开右闭)，并且锁定记录本身,用于解决幻读,

在 InnoDB 默认的隔离级别 RR 下，行锁默认使用的是 Next-Key Lock。但是，如果操作的索引是唯一索引或主键，InnoDB 会对 Next-Key Lock 进行优化，将其降级为 Record Lock，即仅锁住索引本身，而不是范围。

在能使用记录锁或者间隙锁就能避免幻读现象的场景下，next-key lock 就会退化成退化成记录锁或间隙锁。

常见规则

原则 1：加锁的基本单位是 next-key lock。next-key lock 是前开后闭区间。
原则 2：只有访问到的对象才会加锁。
优化 1：索引上的等值查询，
    命中唯一索引，退化为行锁。
    命中普通索引，左右两边的GAP Lock + Record Lock。
优化 2：
    索引上的等值查询，未命中，所在的Net-Key Lock，退化为GAP Lock 。
索引+范围查询： 
    1.等值和范围分开判断。
    2.索引在范围查询的时候 都会访问到所在区间不满足条件的第一个值为止。
    3.如果使用了倒叙排序，按照倒序排序后，检索范围的右边多加一个GAP。
        哪个方向还有命中的等值判断，再向同方向拓展外开里闭的区间。

行锁粒度粗化

在内存中专门分配了一块空间存储锁对象，当该区域满了后，会将行锁粗化为表锁。
进行范围性写操作时，由于要加的行锁较多，此时行锁开销会较大，会粗化成表锁。

插入意向锁

一个事务在插入一条记录的时候，需要判断插入位置是否已被其他事务加了间隙锁（next-key lock 也包含间隙锁）。

如果有的话，插入操作就会发生阻塞，直到拥有间隙锁的那个事务提交为止（释放间隙锁的时刻），在此期间会生成一个插入意向锁，表明有事务想在某个区间插入新记录，但是现在处于等待状态

1.5 乐观锁与悲观锁

乐观锁

在MySQL中则可以通过version版本号+CAS的形式实现乐观锁，即在表中多设计一个version字段，然后在SQL修改时以如下形式操作：

UPDATE ... SET version = version + 1 ... WHERE ... AND version = version;

一般的乐观锁都会配合轮询重试机制，比如上述T1执行失败后，再次执行相同语句，直到成功为止。

这种形式却并不适合所有情况，比如写操作的并发较高时，就容易导致一个事务长时间一直在重试执行，从而导致客户端的响应尤为缓慢。因此乐观锁更加适用于读大于写的业务场景，频繁写库的业务则并不适合加乐观锁。

悲观锁

数据库中的排它锁:for update

1.6 共享排他锁

SMO问题:

在SQL执行期间一旦更新操作触发B+Tree叶子节点分裂，那么就会对整个B+Tree加排它锁，这不但阻塞了后续这张表上的所有的更新操作，同时也阻止了所有试图在B+Tree上的读操作，也就是会导致所有的读写操作都被阻塞，影响巨大

为了解决这种情况,MySQL5.7引入共享排他锁,只锁定B+Tree的某个分支，而并不是锁定整颗B+树，从而做到不影响其他分支上的读写操作

1.7 实现原理

(十)全解MySQL之死锁问题分析、事务隔离与锁机制的底层原理剖析 - 掘金 (juejin.cn)

二、MVCC

MVCC(多版本并发控制Multi-Version Concurrency Control):每个连接到数据库的读者，在某个瞬间看到的是数据库的一个快照，写者写操作造成的变化在写操作完成之前（或者数据库事务提交之前）对于其他的读者来说是不可见的。每行数据都存在一个版本号，每次数据更新时都更新该版本

MVCC=隐藏字段+Undo-log+ReadView

MVCC只能在两个隔离级别使用,区别在于:生成ReadView的时机不同

READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView

而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，数据的可重复读其实就是ReadView的重复使用

实现原理

通过在每一行数据中额外保存两个隐藏的列实现

最近更新的事务ID - TRX_ID（6Bytes）+回滚指针 - ROLL_PTR（7Bytes）

当前行创建时的版本号(最近更新的事务ID)和删除时的版本号(回滚指针)。这里的版本号并不是实际的时间值，而是系统版本号。每开始新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询每行记录的版本号进行比较。每个事务又有自己的版本号，这样事务内执行CRUD操作时，就通过版本号的比较来达到数据版本控制的目的。

首先会去获取表中行数据的隐藏列，然后经过上述一系列判断后，可以得知：目前查询数据的事务到底能不能访问最新版的数据。

如果能，就直接拿到表中的数据并返回，

反之，不能则去Undo-log日志中获取旧版本的数据返回。