mysql事务和隔离级别底层原理浅析-数据库

mysql事务和隔离级别底层原理浅析目录前言一.事务底层原理浅析原子性: 持久性隔离性: 一致性: 二.隔离级别底层原理浅析三.总结前言首先回顾一下什么是事务,事务是数据库操作的最小工作单元,是作为单个逻辑工作单元执行的一系列操作

前言

首先回顾一下什么是事务，事务是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；这些操作作为一个整体一起向系统提交，要么都执行、要么都不执行；事务是一组不可再分割的操作集合（工作逻辑单元）。

事务的特性：

原子性（Atomicity）：原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚。一致性（Consistency）：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。隔离性（Isolation）：一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。持久性（Durability）：指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

一、事务底层原理浅析

原子性：

实现原理：undo log

undo log也被成为回滚日志，它是事务实现原子性和隔离性的基础。当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。

undo log属于逻辑日志，它记录的是sql执行相关的信息。当发生回滚时，InnoDB会根据undo log的内容做与之前相反的工作：对于每个insert，回滚时会执行delete；对于每个delete，回滚时会执行insert；对于每个update，回滚时会执行一个相反的update，把数据改回去。

undo 存放在数据库内部的一个特殊段segment中，这个段称为undo段。undo段位于共享表空间中。undo是逻辑日志，因此只是将数据库逻辑的恢复到原来的样子。undo log会产生redo log,也就是undo log的产生会伴随着redo log的产生，因为undo log也需要持久性的保护。

undo log执行记录是在每次写入数据或者修改数据之前。

undo log使用原理：数据库表每行数据会多两列DATA_TRX_ID和DATA_ROLL_PTR（可能还有一列DB_ROW_ID，当没有默认主键时会自动加上这列）。DATA_TRX_ID表示当前数据的事务版本， DATA_ROLL_PTR 则指向刚刚拷贝到

undo log 链中的旧版本记录，undo log是个链表，如果多个事务多次修改会继续生成undo log并通过DATA_ROLL_PTR建立指向关系。用图说明一下：

这样，一旦事务发生回滚，mysql便可以借助undo log实现数据还原，从而保证未提交事务的原子性。

持久性

实现原理：redo log

由于InnoDB作为MySQL的存储引擎，数据是存放在磁盘中的，为了减少磁盘IO，提高读取性能InnoDB提供了缓存池——Buffer Pool。Buffer Pool中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲：当从数据库读取数据时，会首先从Buffer Pool中读取，如果Buffer Pool中没有，则从磁盘读取后放入Buffer Pool；当向数据库写入数据时，会首先写入Buffer Pool，Buffer Pool中修改的数据会定期刷新到磁盘中（这一过程称为刷脏）。

不过这也带来了一个新的问题，如果MySQL宕机，而此时Buffer Pool中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证。

为了解决这个问题就引入了redo log，也叫重做日志。当数据修改时，除了修改Buffer Pool中的数据，还会在redo log记录这次操作；当事务提交时，会调用fsync接口对redo log进行刷盘。如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复。redo log采用的是WAL（Write-ahead logging，预写式日志），所有修改在提交前先写入日志，保证了数据不会因MySQL宕机而丢失，从而满足了持久性要求。redo log是针对物理页的，并发执行，最后一次提交会覆盖未提交的数据。本地redo log:

redo log也是有缓冲区的——redo log buffer，当事务提交之后会把所有修改信息都刷新到磁盘上。用户也可以通过控制通过变量 innodb_flush_log_at_trx_commit 的值来修改刷新策略（默认1），如设置值为2，控制成每秒刷新，这样事务提

交就会较快，不过可能面临日志丢失的风险。

redo log是在SQL语句执行之后记录的。

既然redo log也需要存储，也涉及磁盘IO为啥还用它？

（1）redo log 的存储是顺序存储，而缓存同步是随机操作。

（2）缓存同步是以数据页为单位的，每次传输的数据大小大于redo log。

redo log是用来恢复数据的用于保障已提交事务的持久化特性。

隔离性：

原理：
(1). 写操作对写操作的影响：锁机制保证隔离性
(2). 写操作对读操作的影响：MVCC保证隔离性

一致性：

一致性比较特殊，前面的原子性、持久性和隔离性都是为一致性服务的，除此之外，一致性还依赖于数据库自我提供的保障，如SQL语法验证，列类型插入数据类型验证，同时也依赖于应用层的保障，如转账操作，需要开发人员进行转账者的余额扣除和接受者的余额增加，如果应用层面出现问题，那么一致性也是无法保障的。

二、隔离级别底层原理浅析

在事务底层原理浅析中，关于隔离性的原理没有过多深入，在此我们简单介绍一下。

首先介绍一下mysql的MVCC(MultiVersion Concurrency Control) 叫做多版本并发控制。它是依赖undo log与read view实现的。undo log上文已经介绍过了，不再赘述，read view（可读视图），这与我们平时理解的数据库视图不同，它是用来判断当前数据版本的可见性的。

readview主要有四个属性：

(1). m_ids 代表生成ReadView时，当前所有活跃的事务ID，活跃的意思就是事务开启了还没提交；

(2). min_trx_id 表示当前活跃的mIds中最小的事务ID；

(3). max_trx_id 表示生成ReadView时，最大的事务ID，它不一定是mIds中最大的事务ID；

(4).creator_trx_id表示创建该ReadView的事务ID。

注意：每开启一个事务，事务ID就自增一次，事务ID可以看做一个全局自增变量。最先开启的事务不一定比后开启的事务先提交，比如长连接，所以不要认为max_trx_id就是mIds中的最大值。

read view是怎样借助上面四个属性，判断事务应该读取那个版本的数据呢？

如果被访问版本的 data_trx_id 小于 m_ids 中的最小值，说明生成该版本的事务在 ReadView 生成前就已经提交了，那么该版本可以被当前事务访问。

如果被访问版本的 data_trx_id 属性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。

如果被访问版本的 data_trx_id 属性值大于ReadView中的max_trx_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。

如果被访问版本的 data_trx_id 属性值在ReadView的min_trx_id和max_trx_id之间，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。

当一个事务要读取一行数据，首先用上面规则判断数据的最新版本也就是那行记录，如果发现可以访问就直接读取了，如果发现不能访问，就通过DATA_ROLL_PTR指针找到undo log，递归往下去找每个版本，知道读取到自己可以读取的版本为止，如果读取不到就返回空。

所以访问数据时，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准：

READ UNCOMMITED (未提交读)：此隔离级别下直接返回记录上的最新值，没有视图概念。因为读不会加任何锁，所以写操作在读的过程中修改数据，所以会造成脏读。好处是可以提升并发处理性能，能做到读写并行。

READ COMMITED (提交读)：此隔离级别下，这个视图是在每个 SQL语句开始执行的时候创建的。InnoDB在 READ COMMITTED，使用排它锁,读取数据不加锁而是使用了MVCC机制。或者换句话说他采用了读写分离机制。

REPEATABLE READ (可重复读)：此隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。

SERIALIZABLE (串行化)：此隔离级别下直接用加锁的方式来避免并行访问。

写到这里，你也许发现了，MySQL中借助MVCC在可重复读隔离级别下其实也杜绝了幻读的发生。