目录
一、数据库并发场景
- 读读：不存在任何问题。
- 读写：有数据安全问题，可能会产生脏读，幻读，不可重复读。
- 写写：有数据安全问题，可能存在更新丢失问题。
那如何解决上面的问题呢？
- 并发事务对数据的读操作不会产生并发问题，所以不用解决；
- 并发事务对数据的读+写，常规操作一般会对要操作的数据加锁来解决并发读+写可能产生的问题，MySQL的InnoDB实现了MVCC来更好地处理读写冲突，可以做到即使存在并发读写，也可以不用加锁，实现"非阻塞并发读"。
- 并发事务对数据的写操作，只能通过加锁(乐观锁/悲观锁)来解决。
两个基本概念：
- 当前读：读取的数据是最新版本，读取数据时还要保证其他并发事务不会修改当前的数据，当前读会对读取的记录加锁。比如：select …… lock in share mode（共享锁）、select …… for update | update | insert | delete（排他锁）。
- 快照读：每一次修改数据，都会在 undo log 中存有快照记录，这里的快照，就是读取undo log中的某一版本的快照。这种方式的优点是可以不用加锁就可以读取到数据，缺点是读取到的数据可能不是最新的版本。一般的查询都是快照读，比如：select * from t_user where id=1; 在MVCC中的查询都是快照度。
二、MVCC介绍
MVCC，全称 Multi-Version Concurrency Control，即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。
MVCC的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖三部分：记录中的 3个隐式字段，undo log ，read view 来实现的。
1.隐式字段
每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRX_ID，DB_ROLL_PTR，DB_ROW_ID等字段。
- DB_TRX_ID
6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID - DB_ROLL_PTR
7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里） - DB_ROW_ID
6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引 - 实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除flag变了。
DB_ROW_ID是数据库默认为该行记录生成的唯一隐式主键，DB_TRX_ID是当前操作该记录的事务ID,而DB_ROLL_PTR是一个回滚指针，用于配合undo log，指向上一个旧版本。
不同事务或者同一事务对于同一条记录的修改会形成一个版本链表，链首的是最新的旧记录，链尾是最旧的旧记录，后台有一个线程purge来定时清除无用的undo log数据。
2.undo log（回滚日志）
undo log主要分为两种：
- insert undo log
代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃。 - update undo log
事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除。
purge线程：
从前面的分析可以看出，为了实现InnoDB的MVCC机制，更新或者删除操作都只是设置一下老记录的deleted_bit，并不真正将过时的记录删除。
为了节省磁盘空间，InnoDB有专门的purge线程来清理deleted_bit为true的记录。为了不影响MVCC的正常工作，purge线程自己也维护了一个read view（这个read view相当于系统中最老活跃事务的read view）;如果某个记录的deleted_bit为true，并且DB_TRX_ID相对于purge线程的read view可见，那么这条记录一定是可以被安全清除的。
对MVCC有帮助的实质是update undo log ，undo log实际上就是存在rollback segment中旧记录链。
3.ReadView(读视图)
什么是 Read View，说白了 Read View 就是事务进行 快照读 操作的时候生产的读视图 (Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的 ID (当每个事务开启时，都会被分配一个 ID , 这个 ID 是递增的，所以最新的事务，ID 值越大)，读视图记录的并不是实际的数据，而是事务的相关信息。
所以我们知道 Read View 主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个 Read View 读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的 undo log 里面的某个版本的数据。
Read View 遵循一个可见性算法，主要是将 要被修改的数据 的最新记录中的 DB_TRX_ID（即当前事务 ID ）取出来，与系统当前其他活跃事务的 ID 去对比（由 Read View 维护），如果 DB_TRX_ID 跟 Read View 的属性做了某些比较，不符合可见性，那就通过 DB_ROLL_PTR 回滚指针去取出 Undo Log 中的 DB_TRX_ID 再比较，即遍历链表的 DB_TRX_ID（从链首到链尾，即从最近的一次修改查起），直到找到满足特定条件的 DB_TRX_ID , 那么这个 DB_TRX_ID 所在的旧记录就是当前事务能看见的最新老版本
我们可以把 Read View 简单的理解成有三个全局属性
trx_list（名称我随意取的）
- 一个数值列表
- 用于维护 Read View 生成时刻系统 正活跃的事务 ID 列表
up_limit_id
- lower water remark
- 是 trx_list 列表中事务 ID 最小的 ID
low_limit_id
- hight water mark
- ReadView 生成时刻系统尚未分配的下一个事务 ID ，也就是 目前已出现过的事务 ID 的最大值 + 1
- 为什么是 low_limit ? 因为它也是系统此刻可分配的事务 ID 的最小值
可见性算法：
- 首先比较 DB_TRX_ID < up_limit_id , 如果小于，则当前事务能看到 DB_TRX_ID 所在的记录，如果大于等于进入下一个判断
- 接下来判断 DB_TRX_ID >= low_limit_id , 如果大于等于则代表 DB_TRX_ID 所在的记录在 Read View 生成后才出现的，那对当前事务肯定不可见，如果小于则进入下一个判断
- 判断 DB_TRX_ID 是否在活跃事务之中，trx_list.contains (DB_TRX_ID)，如果在，则代表我 Read View 生成时刻，你这个事务还在活跃，还没有 Commit，你修改的数据，我当前事务也是看不见的；如果不在，则说明，你这个事务在 Read View 生成之前就已经 Commit 了，你修改的结果，我当前事务是能看见的
举例说明：
RC , RR 级别下的 InnoDB 快照读有什么不同？
正是 Read View 生成时机的不同，从而造成 RC , RR 级别下快照读的结果的不同
- 在 RR 级别下的某个事务的对某条记录的第一次快照读会创建一个快照及 Read View, 将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个 Read View，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个 Read View，所以对之后的修改不可见；
- 即 RR 级别下，快照读生成 Read View 时，Read View 会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见
- 而在 RC 级别下的，事务中，每次快照读都会新生成一个快照和 Read View , 这就是我们在 RC 级别下的事务中可以看到别的事务提交的更新的原因
总之在 RC 隔离级别下，是每个快照读都会生成并获取最新的 Read View；而在 RR 隔离级别下，则是同一个事务中的第一个快照读才会创建 Read View, 之后的快照读获取的都是同一个 Read View。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
