参考博文: 波波烤鸭 (opens new window)

脏读、幻读、不可重复读

1. 脏读

• 脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问 这个数据，然后使用了这个数据。

  张三的工资为5000,事务A中把他的工资改为8000,但事务A尚未提交。
  与此同时，
  事务B正在读取张三的工资，读取到张三的工资为8000。
  随后，
  事务A发生异常，而回滚了事务。张三的工资又回滚为5000。
  最后，
  事务B读取到的张三工资为8000的数据即为脏数据，事务B做了一次脏读。
  

  

2. 不可重复读

不可重复读的重点是修改：同样的条件，你读取过的数据，再次读取出来发现值不一样了

• 是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两 次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不 可重复读。例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果 只有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题。

  在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。
  与此同时，
  事务B把张三的工资改为8000，并提交了事务。
  随后，
  在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。
  

  

3. 幻读

幻读的重点在于新增或者删除：同样的条件，第 1 次和第 2 次读出来的记录数不一样

• 是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。 同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象 发生了幻觉一样。例如，一个编辑人员更改作者提交的文档，但当生产部门将其更改内容合并到该文档的主复本时，发现作者已将未编辑的新材料添加到该文档中。 如果在编辑人员和生产部门完成对原始文档的处理之前，任何人都不能将新材料添加到文档中，则可以避免该问题。

  目前工资为5000的员工有10人，事务A读取所有工资为5000的人数为10人。
  此时，
  事务B插入一条工资也为5000的记录。
  这是，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。
  

  

隔离级别

• MySQL的事务隔离级别有四个

  隔离级别	描述
  READ_UNCOMITTED	读未提交（脏读）最低的隔离级别，一切皆有可能。
  READ_COMMITED	读已提交，ORACLE默认隔离级别，有幻读以及不可重复读风险。
  REPEATABLE_READ	可重复读，解决不可重复读的隔离级别，但还是有幻读风险。 mysql默认级别
  SERLALIZABLE	串行化，最高的事务隔离级别，不管多少事务，挨个运行完一个事务的所有子事务之后才可以执行另外一个事务里面的所有子事务，这样就解决了脏读、不可重复读和幻读的问题了

• READ_COMMITED, REPEATABLE_READ 是常用的两种，mysql默认是REPEATABLE_READ, 隔离级别越高, 性能越差

• 数据库的并发场景

  • 读读：不会存在任何问题，也不需要并发控制
  • 读写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读，需要MVCC控制
  • 写写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失

binlog、undolog、redolog

• binlog 是server层的日志，而redo_log 和undo_log都是引擎层（innodb）的日志
  • 事务的原子性是通过undo log来实现的
  • 事务的持久性是通过redo log来实现的
  • 事务的隔离性是通过 (读写锁+MVCC)来实现的
  • 事务的一致性是通过原子性，持久性，隔离性来实现的！！！

• binlog :

  • binlog 是作为mysql操作记录归档的日志，这个日志记录了所有对数据库的数据、表结构、索引等等变更的操作。也就是说只要是对数据库有变更的操作都会记录到binlog里面来， 可以把数据库的数据当成我们银行账户里的余额，而binlog就相当于我们银行卡的流水。账户余额只是一个结果，至于这个结果怎么来的，那就必须得看流水了。而同样在mysql里我们就是通过binlog来归档、验证、恢复、同步数据。

• redolog

  • redo log 是属于引擎层(innodb)的日志，它的设计目标是支持innodb的“事务”的特性，事务ACID特性分别是原子性、一致性、隔离性、持久性， 一致性是事务的最终追求的目标，隔离性、原子性、持久性是达成一致性目标的手段，根据的文章我们已经知道隔离性是通过锁机制来实现的。 而事务的原子性和持久性则是通过redo log 和undo log来保障的。
  • redo log 能保证对于已经COMMIT的事务产生的数据变更，即使是系统宕机崩溃也可以通过它来进行数据重做，达到数据的一致性，这也就是事务持久性的特征，一旦事务成功提交后，只要修改的数据都会进行持久化，不会因为异常、宕机而造成数据错误或丢失,所以解决异常、宕机而可能造成数据错误或丢是redo log的核心职责。
  • redo log记录的是操作数据变更的日志，听起来好像和binlog有类似的地方，有时候我都会想有了binlog为什么还要redo log，当然从其它地方可以找到很多的理由，但是我认为最核心的一点就是redo log记录的数据变更粒度和binlog的数据变更粒度是不一样的，也正因为这个binlog是没有进行崩溃恢复事务数据的能力的。

• undolog

  • redo log 是也属于引擎层(innodb)的日志，从上面的redo log介绍中我们就已经知道了，redo log 和undo log的核心是为了保证innodb事务机制中的持久性和原子性，事务提交成功由redo log保证数据持久性，而事务可以进行回滚从而保证事务操作原子性则是通过undo log 来保证的。

  • 要对事务数据回滚到历史的数据状态，所以我们也能猜到undo log是保存的是数据的历史版本，通过历史版本让数据在任何时候都可以回滚到某一个事务开始之前的状态。undo log除了进行事务回滚的日志外还有一个作用，就是为数据库提供MVCC多版本数据读的功能。

  • 在Mysql里数据每次修改前，都首先会把修改之前的数据作为历史保存一份到undo log里面的，数据里面会记录操作该数据的事务ID，然后我们可以通过事务ID来对数据进行回滚。

MVCC

MVCC（Multi-Version Concurrency Control）：多版本并发控制，是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。

MVCC 在 MySQL InnoDB 中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。

1.快照读、当前读

• InnoDB的快照读和当前读

  类型	说明
  当前读	像 select lock in share mode (共享锁), select for update; update; insert; delete (排他锁)这些操作都是一种当前读，为什么叫当前读？就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁
  快照读	像不加锁的 select 操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即 MVCC ,可以认为 MVCC 是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本

• 其实MVCC 就是为了实现读-写冲突不加锁，而这个读指的就是快照读, 而非当前读，当前读实际上是一种加锁的操作，是悲观锁的实现.

2. MVCC、快照读、当前读 三者关系

1. MVCC 多版本并发控制是(维持一个数据的多个版本，使得读写操作没有冲突) 的概念，只是一个抽象概念，并非实现
2. 因为 MVCC 只是一个抽象概念，要实现这么一个概念，MySQL 就需要提供具体的功能去实现它，(快照读就是 MySQL 实现 MVCC 理想模型的其中一个非阻塞读功能)。而相对而言，当前读就是悲观锁的具体功能实现
3. 要说的再细致一些，快照读本身也是一个抽象概念，再深入研究。MVCC 模型在 MySQL 中的具体实现则是由 3 个隐式字段，undo 日志 ，Read View 等去完成的，具体可以看下面的 MVCC 实现原理

3. MVCC 优点

• 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能
• 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题

MVCC 工作原理

• MVCC 的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的 3个隐式字段，undo日志 ，Read View 来实现的。

1. 三个隐藏字段

• DB_ROW_ID 是数据库默认为该行记录生成的唯一隐式主键，DB_TRX_ID 是当前操作该记录的事务 ID ,而 DB_ROLL_PTR 是一个回滚指针，用于配合 undo日志，指向上一个旧版本 举例如：

  

• 从上面，我们就可以看出，不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，既链表，undo log 的链首就是最新的旧记录，链尾就是最早的旧记录.

• undolog：回滚日志，保存了事务发生之前的数据的一个版本，作用：

  1. 可以用于回滚
  2. 同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。
  3. 事务开始之前，将当前事务版本生成 undo log，undo log 也会产生 redo log 来保证 undo log 的可靠性。
  4. 当事务提交之后，undo log 并不能立马被删除，而是放入待清理的链表。
  5. 由 purge 线程判断是否有其它事务在使用 undo 段中表的上一个事务之前的版本信息，从而决定是否可以清理 undo log 的日志空间。

2. 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 所在的旧记录就是当前事务能看见的最新老版本.

  

• 举例说明：

• 分析：

• 第二种情况：

• 分析：

• 最后完整的绘图：

总结：能否看到事务修改的数据，取决于可见性算法，可见性算法比较的时候又取决于ReadView中的结果值！因为在不同隔离级别的时候，生成ReadView的时机是不同的RC：每次执行时快照读都会重新生成新的ReadViewRR：只有当第一次事务进行快照读的时候才会生成ReadView，之后的快照读操作都会复用当前的ReadView 。

• 详细解析: https://zhuanlan.zhihu.com/p/491303424