MySQL数据库隔离级别

事务隔离级别

读未提交（read uncommitted）

别人改数据的事务尚未提交，我在我的事务中也能读到。该隔离级别下，会产生脏读。

脏读：A事务读取了B事务未提交的数据，假设B事务回滚了，那么A事务读取到脏数据。

读已提交（read commited）

别人改数据的事务已经提交，我在我的事务中才能读到。该隔离级别下，会产生不可重复读。

不可重复读：不可重复读是指在事务A内，读取了一个数据，事务A还没有结束时，事务B修改了这个数据并提交。紧接着，事务A又读这个数据。事务A两次读到的的数据是不一样的，因此称为是不可重复读。

可重复读（reapeatable read）

别人改数据的事务已经提交，我在我的事务中也读取不到。该隔离级别下，会产生幻读。

幻读：所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻像。InnoDB存储引擎通过多版本并发控制（MVCC）解决了幻读的问题。

串行化（serializable）

我的事务尚未提交，别人就别想改数据。

MVCC多版本并发控制

MVCC(Mutil-Version Concurrency Control)，每条记录在更新的时候都会同时记录一条回滚日志undolog，同一条记录在系统中可以存在多个版本，这就是数据库的多版本并发控制。MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问。

在实现上，数据库里面会面会创建一个视图ReadView，访问的时候以视图的逻辑结果为准 。在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在“已提交读”隔离级别下这个视图是在每个SQL语句开始执行的时候创建的。“读未提交”隔离级别下直接返回记录上的最新值，没有视图概率。“串行化”隔离级别是直接用加锁的方式来避免并行访问的。

也就是说已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的ReadView,而可重复读隔离级别则在第一次读的时候生成一个ReadView，之后的读都复用之前的ReadView。

redo、undo、bin、relay log 区别

undo log

为了实现事务原子性，要么全部完成commit，要么全部回滚rollback，Innodb用于实现mvcc（多版本并发控制）

redo log

如果使用undo log作为持久化数据，意味着修改数据和undo log必须同时写入磁盘持久化，这必定带来巨大的磁盘io，解决方案为了平衡磁盘io和一致性，引入redo log。

数据和undo log可定时从缓冲刷至磁盘，但是redo log必须实时写入磁盘，当系统奔溃时，可依据redo log进行数据重做。redo log是InnoDB存储引擎层的日志。

bin log

redo log可以实现数据重做，那为什么要使用binlog？因为redo log是Innodb实现的物理日志，一旦涉及到多种存储引擎，无法进行重做。bin log 记录下所有数据的更改，可用于本机数据恢复和主从同步。

relay（中继） log

Mysql 主节点将binlog写入本地，从节点定时请求增量binlog，主节点将binlog同步到从节点。从节点单独进程会将binlog 拷贝至本地 relaylog中。从节点定时重放relay log。