Mysql学习笔记：事务隔离级别

这个问题其实有很多人都已经教科书式的总结了很多遍，如：

隔离级别	中文描述	此级别问题(面试官喜欢用这个)
READ UNCOMMITED	未提交读	脏读
READ COMMITED	提交读	不可重复读
REPEATABLE READ	可重复读	幻读
SERIALIZABLE	串行化	锁

但是在这个表格中最后一列的问题因何产生，很多人会不明白其中的缘由。我先说下我的理解，然后再来一点点解释：

事务隔离的四个级别可以先用“事务是否可并发”来划分成两个对立面来理解：

1. 事务不可并发在 Mysql 中只有 SERIALIZABLE 这一级别满足；其它的当然是事务可并发了；
2. 事务不可并发，Mysql 选择了串行化这一实现方式，因此引入了锁，也带来了性能问题；
3. 事务可并发，因此在多个并发的事务期间，我们并不知道哪个事务的哪段逻辑（begin/rollback/commit）会在下一个时间片内被执行；

并发事务带来的问题

在上面的描述中，2、3是对1的一个扩展，2不难理解，但是 3 可能有些生硬，我们可以简单的换种理解方式，

1. 假设同一时间有两个事务: A & B，并且事务 A 执行 update，事务 B 执行 select。
2. 假设事务的开启、提交、回滚及事务中执行的 Action 都能在一个 cpu 时间片内完成，那么可把 A&B 的事务拆成如下逻辑调用段：

#	事务A	事务B
1	begin	begin
2	update	select
3	commit	commit
4	rollback	rollback

基于上面的假设，我们再来理解事务并发情况下各种问题的产生：

脏读

1. A begin => update 后让 cpu
2. 同时B begin => select，但是事务 B 很心大，并没有去验证 A 的有效性，读到了 A update 后的数据；
3. A 在下一个 cpu 时间又得到了调度，A 发现自己刚才的操作无效了，A rollback 得到了执行，但是它无法告知 B 了，所以 B 读到的数据是无效的；

不可重复读

知道了脏读的原因后，为了解决这个问题，Mysql 规定 B 读的数据只能读取已经 commit 状态的数据：

1. A begin => update 后让 cpu
2. 同时 B begin => select，这次 B 很小心地验证 A 的数据是否 commit 了，B 这次读到了 A begin 以前的数据；
3. 事务 A 在下一个 cpu 时间又得到了调度，A commit 了；
4. B 再次 select，但是已经 select 到了 A commit 后的数据了，B 在 A commit 前后读到了两次不一样的数据，即不可重复读了；

幻读

知道了不可重复读的原因后，Mysql 又规定，既然 B 第一次读到的是 A commit 前的数据，那么在事务 B 中后面无论多少次 select 都只能读到 A commit 之前的数据。但是问题又来了：

1. 这次 A 不是 update 了，而是 insert，B select 也不是单条了，而是 select range；
2. B 在 A commit 前后两次 select range 会发现结果的数量不一至；这就是幻读；

InnoDB 针对幻读也做了处理：MVCC，在每一行后都有隐藏的两列版本号来实现；大致与处理不可重复读相同；

不可并发带来的问题

Mysql 用串行来实现不可并发，虽说是串行，但是要保证事务被正确的放入串行队列中，就会引入锁等机制，增加了开销，所以非不得已，将不会使用此级别。

三岁于辛 的博客《Mysql学习笔记：事务隔离级别》