MYSQL - 隔离级别

SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。

Read Uncommitted（读取未提交内容）
在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

A可以读取到B还未提交的事务。

Read Committed（读取提交内容）
这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。

A只能读取到B已经提交的事务。并且A事务中两次读到的内容不一致，原有就是B提交事务。

Repeatable Read（可重读）
这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

A只能读取到B已经提交的事务。并且A事务中两次读到的内容一致，A事务结束后再读取会读取到B提交事务。

Serializable（可串行化）
这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

A事务未提交，B事务就等待。

1. 数据脏读
事务a修改了某条数据，然后事务b读取了事务a修改的该条数据，然后事务a由于某些原因，事务a回滚了，这样事务b读到的数据就和回滚的数据不同了，这时事务b读取的数据就是脏数据。概况一句话就是一个事务读取了另一个事务未提交的数据。

读到了还未提交事务的数据。

2. 数据幻读
事务a按一定条件读取了该表的一些数据，然后事务b想该表插入了一些满足事务a查询条件的数据，当事务a再次以相同条件查询数据时，会发现多出来一些数据，就好像产生了幻觉一样，我们称为幻读

两次事务读到的数据不一致。中间有新事务提交。

3. 不可重复读
事务a读取了某条数据，事务a没有提交，然后事务b修改了该条数据，这时事务a再次读取该条数据，这样两次读取的数据不同，我们成为该条数据为不可重复读。概况一句话就是一个事务多次读取某条数据，发现读取的数据不完全相同。

一次事务中不允许多次读，会发生数据不一致。中间有新事务提交。

Innodb的事务相关概念

1. redo log

redo log就是保存执行的SQL语句到一个指定的Log文件，当Mysql执行recovery时重新执行redo log记录的SQL操作即可。当客户端执行每条SQL（更新语句）时，redo log会被首先写入log buffer；当客户端执行COMMIT命令时，log buffer中的内容会被视情况刷新到磁盘。redo log在磁盘上作为一个独立的文件存在，即Innodb的log文件。

redo log包括两部分：一是内存中的日志缓冲(redo log buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(redo log file)，该部分日志是持久的。

2. undo log

与redo log相反，undo log是为回滚而用，具体内容就是copy事务前的数据库内容（行）到undo buffer，在适合的时间把undo buffer中的内容刷新到磁盘。undo buffer与redo buffer一样，也是环形缓冲，但当缓冲满的时候，undo buffer中的内容会也会被刷新到磁盘；与redo log不同的是，磁盘上不存在单独的undo log文件，所有的undo log均存放在主ibd数据文件中（表空间），即使客户端设置了每表一个数据文件也是如此。

undo log有两个作用：提供回滚和多个行版本控制(MVCC)。

3. rollback segment

回滚段这个概念来自Oracle的事物模型，在Innodb中，undo log被划分为多个段，具体某行的undo log就保存在某个段中，称为回滚段。可以认为undo log和回滚段是同一意思。

4. 锁

Innodb提供了基于行的锁，如果行的数量非常大，则在高并发下锁的数量也可能会比较大，据Innodb文档说，Innodb对锁进行了空间有效优化，即使并发量高也不会导致内存耗尽。
对行的锁有分两种：排他锁、共享锁。共享锁针对读，排他锁针对写，完全等同读写锁的概念。如果某个事务在更新某行（排他锁），则其他事物无论是读还是写本行都必须等待；如果某个事物读某行（共享锁），则其他读的事物无需等待，而写事物则需等待。通过共享锁，保证了多读之间的无等待性，但是锁的应用又依赖Mysql的事务隔离级别。

5. 隔离级别

隔离级别用来限制事务直接的交互程度，目前有几个工业标准：

• READ_UNCOMMITTED：脏读
• READ_COMMITTED：读提交
• REPEATABLE_READ：重复读
• SERIALIZABLE：串行化

Innodb对四种类型都支持，脏读和串行化应用场景不多，读提交、重复读用的比较广泛。

MVCC(Multiversion Concurrency Control) 多版本并发控制

MVCC可以认为是行级锁的一个变种，它可以在很多情况下避免加锁操作，因此开销更低。MVCC的实现大都都实现了非阻塞的读操作，写操作也只锁定必要的行。InnoDB的MVCC实现，是通过保存数据在某个时间点的快照来实现的。一个事务，不管其执行多长时间，其内部看到的数据是一致的。 也就是事务在执行的过程中不会相互影响。下面我们简述一下MVCC在InnoDB中的实现。

InnoDB的MVCC，通过在每行记录后面保存两个隐藏的列来实现：一个保存了行的创建时间，一个保存行的过期时间（删除时间），当然，这里的时间并不是时间戳，而是系统版本号，每开始一个新的事务，系统版本号就会递增。 在RR隔离级别下，MVCC的操作如下：

1. select操作。a. InnoDB只查找版本早于（包含等于）当前事务版本的数据行。 可以确保事务读取的行，要么是事务开始前就已存在，或者事务自身插入或修改的记录。b. 行的删除版本要么未定义，要么大于当前事务版本号。 可以确保事务读取的行，在事务开始之前未删除。
2. insert操作。将新插入的行保存当前版本号为行版本号。
3. delete操作。将删除的行保存当前版本号为删除标识。
4. update操作。变为insert和delete操作的组合，insert的行保存当前版本号为行版本号，delete则保存当前版本号到原来的行作为删除标识。

由于旧数据并不真正的删除，所以必须对这些数据进行清理，innodb会开启一个后台线程执行清理工作，具体的规则是将删除版本号小于当前系统版本的行删除，这个过程叫做purge。

最后

以上就是痴情航空为你收集整理的MYSQL - 隔离级别的全部内容，希望文章能够帮你解决MYSQL - 隔离级别所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。