MySqlACID实现原理

MySql ACID实现原理

1. MVCC-多版本并发控制

1.0 什么是MVCC

为了保证一致性，可以使用锁，但是锁会降低读写效率，MVCC就是为了保证读写效率的一个替代方案。

MVCC是基于快照读和可见性算法的一个多版本控制算法，即在不同的隔离级别下采用不同的可见性算法，解决读写冲突的算法。

1.1 事务隔离级别

1.2 快照读、当前读和Read View

数据隐藏字段：

• DB_TRX_ID：最近创建或者修改该记录的事务id
• DB_ROW_ID：隐藏主键
• DB_ROLL_PTR：回滚指针，指向上一个版本

undolog：回滚日志。保存了数据的历史版本状态，数据的回滚指针指向在undolog中的地址。undolog是逻辑日志，记录的是一条使日志状态回滚的记录；

redolog：重做日志，是物理的日志。

readview：事务在进行快照读的时候产生的读视图，不同隔离级别下readview生成的时机是不同的；

• trx_list：系统活跃的事务id
• up_limit：列表中最小的事务id
• low_limit_id：系统尚未分配的下一个事务id
• creator_trx_id: 创建当前read view的事务版本号；

1.3 可见性算法

可见性算法基于readView

if db_trx_id

• 如果数据事务id小于当前readview的最小活跃事务id，说明该数据一定是该当前readView生成之前就修改了的；
• 如果数据事务id等于readView的事务版本号，说明这个数据就是当前事务生成的；

else if db_trx_id >= low_limit_id：不显示

• 如果数据事务id大于readView的最大id时，说明该数据是在该readView生成之后产生的

else db_trx_id是否在活跃事务（trx_ids）中

• 不存在：说明readView产生时事务已经commit了，因此可以显示
• 已存在：说明readView生成时，该事务还活跃，并且没有commit，因为不可见

2. 四大特点-ACID

2.1 持久性

持久性的实现：由于磁盘查询比较慢，mysql使用了缓存（Buffer Pool）。但是如果mysql宕机，缓存中尚未存入磁盘的数据就回丢失。而数据修改时，除了修改缓存中的数据，还会用redo log记录这次操作，如果服务器宕机重启时就可以使用redolog对数据库进行恢复。redolog采用的是WAL，从而满足了持久性的要求。在事务提交时，也需要将redolog的日志存入磁盘。

write ahead log：先写日志，再写数据。因为将数据写入磁盘是随机读写，而写日志是顺序读写，顺序读写速度快于随机读写；

redolog和binlog：

• 作用不同：redo log是用于crash recovery的，保证MySQL宕机也不会影响持久性；binlog是用于point-in-time recovery的，保证服务器可以基于时间点恢复数据，此外binlog还用于主从复制。
• 层次不同：redo log是InnoDB存储引擎实现的，而binlog是MySQL的服务器层(可以参考文章前面对MySQL逻辑架构的介绍)实现的，同时支持InnoDB和其他存储引擎。
• 内容不同：redo log是物理日志，内容基于磁盘的Page；binlog的内容是二进制的，根据binlog_format参数的不同，可能基于sql语句、基于数据本身或者二者的混合。
• 写入时机不同：binlog在事务提交时写入；redo log的写入时机相对多元：

为什么redolog的存盘比直接将缓存中的数据写入磁盘更快：

1. 刷脏是随机IO，但是redolog是追加操作，是顺序io
2. 刷脏以page为单位，每个页的小修改都要整页写入；而redolog只包含真正需要写入的部分，无效io大量减少；

2.2 原子性

原子性的实现：使用undolog实现原子性。当事务对数据库进行修改时，innodb会生成相应的undolog，如果此时事务执行失败或者调用了rollback，导致事务出现回滚，就可以利用undolog进行数据恢复。

2.3 隔离性

隔离性的实现：隔离性由锁与MVCC共同实现。其中锁解决写写冲突，MVCC解决读写冲突

读写冲突：读写冲突问题有脏读、不可重复读、幻读；innodb使用mvcc可以在不同隔离级别下解决这些问题的出现；

写写冲突：隔离性要求同一条数据在同一时间只能被一个事务进行修改，因此使用锁来控制；

3. MVCC解决读写冲突

3.1 脏读、不可重复读、幻读

脏读：读取到了其他事务未提交的数据修改；

不可重复度：一个事务中几次读取的数据不一致；这是由于事务执行期间，有其他事务修改了数据并且提交；

幻读：一个事务中几次读取的数据条数不一致，也可以说是读取到了其他事务对数据的增删操作；这是由于事务执行期间，有其他事务增加或删除了数据并提交；

对应隔离级别：

MVCC在不同隔离级别下的可见性算法不同，因此在不同级别下可以防止脏读、不可重复读、幻读等问题的出现；

在RC级别下，每一个快照读都会生成并获取最新的readView;

在RR级别下，只有事务的第一个快照读才会创建readView；

3.2 脏读

当事务A在T3时间节点读取zhangsan的余额时，会发现数据已被其他事务修改，且状态为未提交。此时事务A读取最新数据后，根据数据的undo log执行回滚操作，得到事务B修改前的数据，从而避免了脏读

3.3 不可重复读

当事务A在T2节点第一次读取数据时，会记录该数据的版本号（数据的版本号是以row为单位记录的），假设版本号为1；当事务B提交时，该行记录的版本号增加，假设版本号为2；当事务A在T5再一次读取数据时，发现数据的版本号（2）大于第一次读取时记录的版本号（1），因此会根据undo log执行回滚操作，得到版本号为1时的数据，从而实现了可重复读。

3.4 幻读

• innodb在RR隔离等级下，使用next-key lock避免了幻读现象；
• next-key lock：是一种组合锁，间隙锁和行锁合称next-key lock；next-key lock是前开后闭的；

当事务A在T2节点第一次读取0

4. 锁

单条索引记录上加锁，record lock锁住的永远是索引，而非记录本身，即使该表上没有任何索引，那么innodb会在后台创建一个隐藏的聚集主键索引，那么锁住的就是这个隐藏的聚集主键索引。所以说当一条sql没有走任何索引时，那么将会在每一条聚集索引后面加X锁，这个类似于表锁，但原理上和表锁应该是完全不同的。

4.1 锁的分类

按粒度分：分为表锁和行锁（Record Lock），不同引擎支持的粒度不一样，myisam只支持表锁，innodb支持表锁和行锁；当没有索引时，行锁会失效，变成表锁；等值判断时，varchar必须添加单引号，否则mysql会做自动类型转换，并且导致索引失效；

按操作分：分为写锁和读锁。读锁是共享锁，其他事务可以读取但是不可以写；写锁是排他锁，其他事务不可以进行读取或写操作；

4.2 悲观锁和乐观锁

悲观锁：悲观锁就是数据库层面的锁，如读写锁；但是读写锁会降低数据库读写的效率；

乐观锁：乐观锁是一种基于数据版本实现的并发控制，是不使用锁的。在读写事务，在真正的提交之前，不加读/写锁，而是先看一下数据的版本/时间戳，等到真正提交的时候再看一下版本/时间戳，如果两次相同，说明别人期间没有对数据进行过修改，那么就可以放心提交；如果遇到冲突，则需要回退。

悲观锁和乐观锁使用：在资源冲突不激烈的场合，使用乐观锁性能较好；但是如果资源冲突严重，乐观锁的实现会导致事务反复回滚重试，这样不如直接使用悲观锁。

4.3 乐观锁和MVCC

MVCC：MVCC是用于解决读-写冲突的无锁并发控制，基于快照隔离机制进行多版本并发控制，即为每一个修改都保存一个版本快照；主要解决了脏读和不可重复读；

乐观锁：乐观锁是用于解决写-写冲突的无锁并发控制，主要通过版本比较和回退避免了写-写冲突的问题；

4.4 间隙锁（Gap Lock）

在RR隔离级别下无法避免幻读的问题，因此引入间隙锁来解决幻读问题。

行锁和MVCC都是针对已有的数据进行的控制，但是对新增的数据没法进行控制，因此需要对一定范围内的数据进行加锁；在RR隔离级别下，数据库是通过行锁和间隙锁共同组成的；

在进行范围判断时，会将范围类的所有键值都锁定，即使该键值并不存在；

使用间隙锁的条件：必须是在RR级别下。是一个范围的当前读操作或者是一个非唯一索引的等值判断；

4.5 Next Key Lock

Next Key Lock是一种组合锁，间隙锁和行锁合称next-key lock；next-key lock是前开后闭的；

mysql加锁的基本单位是next-key lock；

4.6 加锁规则

加锁规则包含两个原则，两个优化，一个bug：

1. 原则1：加锁单位是next-key lock，next-key lock是前开后闭的；
2. 原则2：查找过程中访问到的对象才会加锁；
3. 优化1：索引上的等值查询，向唯一索引加锁时，next-key lock退化为行锁；
4. 优化2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock退化为间隙锁；
5. bug：唯一索引上的范围查询会访问到不满足条件的第一个值为止；