Read Uncommitted(读取未提交内容)
在该隔离级别, 所有事务都可以看到其他未提交事务的执行结果本隔离级别很少用于实际应用, 因为它的性能也不比其他级别好多少读取未提交的数据, 也被称之为脏读(Dirty Read)
Read Committed(读取提交内容)
这是大多数数据库系统的默认隔离级别 (但不是 MySQL 默认的) 它满足了隔离的简单定义: 一个事务只能看见已经提交事务所做的改变这种隔离级别 也支持所谓的不可重复读(Nonrepeatable Read), 因为同一事务的其他实例在该实例处理其间可能会有新的 commit, 所以同一 select 可能返回不同结果
Repeatable Read(可重读)
这是 MySQL 的默认事务隔离级别, 它确保同一事务的多个实例在并发读取数据时, 会看到同样的数据行不过理论上, 这会导致另一个棘手的问题: 幻读 (Phantom Read)简单的说, 幻读指当用户读取某一范围的数据行时, 另一个事务又在该范围内插入了新行, 当用户再读取该范围的数据行时, 会发现有新的幻影 行 InnoDB 和 Falcon 存储引擎通过多版本并发控制 (MVCC,Multiversion Concurrency Control) 机制解决了该问题
Serializable(可串行化)
这是最高的隔离级别, 它通过强制事务排序, 使之不可能相互冲突, 从而解决幻读问题简言之, 它是在每个读的数据行上加上共享锁在这个级别, 可能导致大量的超时现象和锁竞争
我这里解释一下 读写提交内容 和 可重读 的区别
假设有两个事务 T1, T2
读写提交内容:
T1 insert 了一条数据, T2 此时看不到, 等 T1commit 了以后, T2 才看到了这就造成了 T2 前后两次 select 的内容不一致, 也就造成了不可重读的原因
可重读:
T1 insert 了一条数据, T2 此时看不到, 等 T1 commit 了以后, T2 还是看不到等 T2 事务进行提交了以后, 在进行 select, 发觉, 卧槽, 数据怎么多了一条出来, 感觉出现了幻觉, 即幻读;
MVCC 机制:
多版本并发控制 (Multiversion Concurrency Control)MySQL 默认隔离级别为 Repeatable Read(可重读) 那么 MySQL 如何解决幻读的
就是利用 MVCC 机制
什么是多版本并发控制呢 ? 其实就是在每一行记录的后面增加两个隐藏列, 记录创建版本号和删除版本号, 而每一个事务在启动的时候, 都有一个唯一的递增的版本号
只有 read-committed 和 repeatable-read 两种事务隔离级别才能使用 MVCC
read-uncommited 由于是读到未提交的, 所以不存在版本的问题
而 serializable 则会对所有读取的行加锁
来源: http://www.linuxidc.com/Linux/2018-03/151405.htm