一、数据库事务隔离级别

数据库事务的隔离级别有4种，由低到高分别为Read uncommitted （读未提交）、Read committed（读提交） 、Repeatable read（可重复读） 、Serializable （串行化）。

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

在数据库多个事务并发执行的情况下，不同的隔离级别可能会出现脏读、不可重复读、幻读这几种问题。

脏读：读取到未提交的数据。事务A对某条数据进行了修改，但还未提交，这时事务B读取到了这条未提交的数据。如果事务A出错回滚，事务B读取到的数据就是一条脏数据。
不可重复读： 同一事务内多次查询某条数据的结果不一致。事务A对某条数据执行了两次查询，在这两次查询的时间间隔内，事务B对该条数据执行了修改（update），导致事务A的两次查询结果不一致。
幻读： 同一事务内多次查询的结果集不一致（多或少了几条数据）。事务A以相同的查询条件执行了两次查询，在这两次查询的时间间隔内，事务B新增或删除（insert|delete）了几条数据，导致事务A的两次查询结果集不一致。

2、四种隔离级别

读未提交 （Read uncommitted）
最低隔离级别，允许事务读取其他事务未提交的更改。可能导致脏读、不可重复读、幻读问题。

读提交（Read Committed）
事务只能读取到已提交的数据。可以解决脏读问题，但是还会有可能不可重复读、幻读问题。

可重复读(Repeated Read)
专门针对“不可重复读”这种情况而制定的隔离级别。可以解决脏读和不可重复读问题，但还是有可能出现幻读问题。MYSQL默认的隔离级别

串行化（Serializable）
最高隔离级别，所有事务都串行化顺序执行，不存在并发，从而完全防止脏读、不可重复读和幻读问题。但是这种隔离级别性能较低，基本不会使用。

二、多版本并发控制（MVCC）

1、什么是多版本并发控制（MVCC）

多版本并发控制英文全称是 Multiversion Concurrency Control，简称 MVCC。

MVCC是通过保存数据行的历史版本，组成版本链，对比事务ID与版本号来确定当前事务应该使用哪个历史版本数据，而无需加锁就可以保证事务的隔离效果，可以认为是一种不加锁的行锁，可以提高数据库的性能。

MySQL的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制（MVCC）。不仅是MySQL，包括Oracle、PostgreSQL等其他数据库系统也都实现了MVCC，但各自的实现机制不尽相同，因为MVCC没有一个统一的实现标准，典型的有乐观（optimistic）并发控制和悲观（pessimistic）并发控制。

2、MVCC可以解决哪些问题

（1）读写之间阻塞的问题
MVCC可以让读写操作互不阻塞，即读不阻塞写，写不阻塞读。相较于普通锁（串行运行）、读写锁（可以实现读读并发），MVCC提升数据库事务并发处理能力。
（2）降低了死锁的概率
MVCC大多数情况不用加锁，写数据时也只是加行锁，降低了死锁的概率
（3） 解决一致性读的问题
一致性读也叫快照读，当查询数据库在某个时间点的快照时，只能看到这个时间点之前事务提交更新的结果，或者本事务提交的结果，而不能看到这个时间点之后事务提交的更新的结果。

3、快照读与当前读

在MySQL InnoDB中，MVCC主要是为了提高数据库并发性能，以更好的方式处理读-写冲突，不用加锁实现并发读-写。这个读就是快照读，而非当前读，当前读实际上是一种加锁的操作，是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。
（1）快照读
快照读又叫一致性读，读取的是快照数据。是一种一致性不加锁的读。不加锁的简单的 SELECT 都属于快照读。例如：

SELECT * FROM t WHERE id=1

快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。
（2）当前读
当前读读取的是记录的最新版本（最新数据，而不是历史版本的数据），读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。加锁的 SELECT，或者对数据进行增删改都会进行当前读。

SELECT * FROM t LOCK IN SHARE MODE; # 共享锁

SELECT * FROM t FOR UPDATE; # 排他锁

INSERT INTO t values ... # 排他锁

DELETE FROM t WHERE ... # 排他锁

UPDATE t SET ... # 排他锁

4、InnoDB的MVCC原理

（1）隐藏字段和Undo Log版本链

隐藏字段：
对于使用 InnoDB 存储引擎的表来说，它的聚簇索引的叶子节点为数据页，存放的就是整张表的数据行，而每个数据行中有一些重要的隐藏字段。

• DB_ROW_ID：大小为6字节，默认主键列，如果表没有设置主键，InnoDB会自动生成该隐藏主键列。
• DB_TRX_ID：大小为6字节，生成该行数据历史版本的事务ID。
• DB_ROLL_PTR：大小为7字节，回滚指针，指向上一个版本的Undo log，InnoDB 便是通过这个指针找到之前版本的数据，该行数据的所有版本记录都在undo中通过链表形式组织在一起。

另外每条记录的头信息（record header）里都有一个专门的 bit（deleted_flag）来表示当前记录是否已经被删除
Undo log版本链：
每次对数据行进行改动，都会生成一条undo日志，每条undo日志也都有一个 DB_ROLL_PTR属性，INSERT 操作对应的undo日志没有该属性，因为该记录并没有更早的版本。版本链示例如下：

（2）ReadView

在多事务并发修改同一行数据的情况下，MVCC通过隐藏字段和Undo Log生成了该行记录的历史版本快照，并组成了版本链。但是事务读取数据时该读取哪个版本的数据，需要一个读取机制来确定。这时就用到了ReadView（可读视图）。
设计思路：
（1）使用 READ UNCOMMITTED 隔离级别的事务，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好
（2）使用 SERIALIZABLE 隔离级别的事务，InnoDB规定使用加锁的方式来访问记录
（3）使用 READ COMMITTED 和 REPEATABLE READ 隔离级别的事务，都必须保证读到已经提交了的 事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的，这是ReadView要解决的主要问题

ReadView内容：
ReadView主要包含以下4个内容：
（1）creator_trx_id
创建当前ReadView的事务ID。注意只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会为事务分配事务ID，否则在一个只读事务中的事务ID值都默认为0。
（2）trx_ids
生成ReadView时，当前系统活跃的事务ID集合，活跃的事务表示还未提交的事务。
（3）up_limit_id
活跃的事务中，最小的事务ID
（4）low_limit_id
表示生成ReadView时系统中应该分配给下一个事务的 id 值，即最大事务ID+1。

ReadView的规则：
（1）如果某行数据被访问版本的trx_id属性值与ReadView中的 creator_trx_id 值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。

（2）如果某行数据被访问版本的trx_id属性值小于ReadView中的 up_limit_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。

（3）如果某行数据被访问版本的trx_id属性值大于或等于ReadView中的 low_limit_id 值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。

（4）如果某行数据被访问版本的trx_id属性值在ReadView的 up_limit_id 和 low_limit_id 之间，那就需要判断一下trx_id属性值是不是在 trx_ids 列表中。
a. 如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问
b. 如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问

（3）MVCC快照读的整体流程

当查询一条记录的时候，系统通过如下流程MVCC找到合适的记录：

（1）首先获取事务自己的版本号，也就是事务 ID

（2）获取 ReadView

（3）查询得到的数据，然后与 ReadView 中的事务版本号进行比较

（4）如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照

（5）最后返回符合规则的数据

如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性。以此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对该事务完全不可见，查询结果就不包含该记录。

（4）MVCC解决不可重复读和幻读原理

当隔离级别为读提交（Read Committed）时，一个事务中的每一次 SELECT 查询都会重新获取一次ReadView。当隔离级别为可重复读(Repeated Read)时，一个事务只在第一次 SELECT 的时候会获取一次ReadView，而后面所有的SELECT都会复用这个ReadView。

1）READ COMMITTED隔离级别

假设事务A、B的事务ID分别为10、20，并且事务正在执行，还未提交

# Transaction A ID=10
BEGIN;
UPDATE t SET name="李四" WHERE id=1;
UPDATE t SET name="王五" WHERE id=1;
# Transaction B iD=20
BEGIN;
UPDATE t SET name="赵六" WHERE id=1;

此时id为1的数据的版本链如下：

此时，另一个事务C开始执行

# 使用READ COMMITTED隔离级别的事务C ID=21
BEGIN;
# 事务A和B都未提交
# SELECT1
SELECT * FROM t WHERE id = 1; # 得到的列name的值为'张三'

SELECT1生成的ReadView的trx_ids=[10,20,21]，up_limit_id=10，low_limit_id=22，creator_trx_id为0。从“赵六”那个版本开始查找，因为10、20都在trx_ids里，所以符合的版本只有trx_id=5的版本数据。

此时，把事务A提交

# Transaction A ID=10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
COMMIT;

然后在事务C中继续查询

# 使用READ COMMITTED隔离级别的事务C ID=21
BEGIN;
# 事务A和B都未提交
# SELECT1
SELECT * FROM t WHERE id = 1; # 得到的列name的值为'张三'
#SELECT2
SELECT * FROM t WHERE id = 1; # 得到的列name的值为'王五'

SELECT2会生成新的ReadView，新ReadView的trx_ids=[20,21]，up_limit_id=20，low_limit_id=22，creator_trx_id为0。还是从“赵六”那个版本开始查找，此时只有20在trx_ids里。所以trx_id=10的版本对SELECT2是可见的，SELECT2查找到的结果就是“王五”那个版本数据。

2）REPEATABLE READ隔离级别

操作同上。但是在SELECT2时，REPEATABLE READ隔离级别是不会重新生成ReadView的，所以SELECT2使用的还是SELECT1的ReadView。所以查出来的结果和SELECT1是一致的，都是trx_id=5的版本数据。这样就解决了不可重复读的问题。

（5）MVCC解决幻读原理

假设表t中有一条id为1的数据，trx_id=10

现在有事务A（ID=20）、事务B（ID=30）并行执行

# Transaction A ID=20
BEGIN;
#SELECT1
SELECT * FROM t WHERE id >= 1; 

SELECT创建的ReadView的内容为trx_ids=[20,30] ， up_limit_id=20 ， low_limit_id=31 ， creator_trx_id=0。根据ReadView的规则，id=1的数据的trx_id=10<up_limit_id,所以事务A能查出来。

此时，事务B插入两条数据，并提交

# Transaction B ID=30
BEGIN;
insert into t(id,name) values(2,'李四');
insert into t(id,name) values(3,'王五');
COMMIT;

然后，事务A再次查询

# Transaction A ID=20
BEGIN;
#SELECT1
SELECT * FROM t WHERE id >= 1; 
#SELECT2
SELECT * FROM t WHERE id >= 1; 

因为是REPEATABLE READ隔离级别，SELECT2不创建新的ReadView，使用SELECT1的ReadView。ReadView的内容为trx_ids=[20,30] ， up_limit_id=20 ， low_limit_id=31 ， creator_trx_id=0。因为id为2,3的两条数据的trx_id=30,在trx_ids里，所以事务A不能查出来。

所以MYSQL的InnoDB在REPEATABLE READ隔离级别下，不会出现幻读的情况。