这个问题其实有很多人都已经教科书式的总结了很多遍，如：
| 隔离级别 | 中文描述 | 此级别问题(面试官喜欢用这个) |
|---|---|---|
| READ UNCOMMITED | 未提交读 | 脏读 |
| READ COMMITED | 提交读 | 不可重复读 |
| REPEATABLE READ | 可重复读 | 幻读 |
| SERIALIZABLE | 串行化 | 锁 |
但是在这个表格中最后一列的问题因何产生，很多人会不明白其中的缘由。我先说下我的理解，然后再来一点点解释：
事务隔离的四个级别可以先用“事务是否可并发”来划分成两个对立面来理解：
- 事务不可并发在 Mysql 中只有 SERIALIZABLE 这一级别满足；其它的当然是事务可并发了；
- 事务不可并发，Mysql 选择了串行化这一实现方式，因此引入了锁，也带来了性能问题；
- 事务可并发，因此在多个并发的事务期间，我们并不知道哪个事务的哪段逻辑（begin/rollback/commit）会在下一个时间片内被执行；
并发事务带来的问题
在上面的描述中，2、3是对1的一个扩展，2不难理解，但是 3 可能有些生硬，我们可以简单的换种理解方式，
- 假设同一时间有两个事务: A & B，并且事务 A 执行 update，事务 B 执行 select。
- 假设事务的开启、提交、回滚及事务中执行的 Action 都能在一个 cpu 时间片内完成，那么可把 A&B 的事务拆成如下逻辑调用段：
| # | 事务A | 事务B |
|---|---|---|
| 1 | begin | begin |
| 2 | update | select |
| 3 | commit | commit |
| 4 | rollback | rollback |
基于上面的假设，我们再来理解事务并发情况下各种问题的产生：
脏读
- A begin => update 后让 cpu
- 同时B begin => select，但是事务 B 很心大，并没有去验证 A 的有效性，读到了 A update 后的数据；
- A 在下一个 cpu 时间又得到了调度，A 发现自己刚才的操作无效了，A rollback 得到了执行，但是它无法告知 B 了，所以 B 读到的数据是无效的；
不可重复读
知道了脏读的原因后，为了解决这个问题，Mysql 规定 B 读的数据只能读取已经 commit 状态的数据：
- A begin => update 后让 cpu
- 同时 B begin => select，这次 B 很小心地验证 A 的数据是否 commit 了，B 这次读到了 A begin 以前的数据；
- 事务 A 在下一个 cpu 时间又得到了调度，A commit 了；
- B 再次 select，但是已经 select 到了 A commit 后的数据了，B 在 A commit 前后读到了两次不一样的数据，即不可重复读了；
幻读
知道了不可重复读的原因后，Mysql 又规定，既然 B 第一次读到的是 A commit 前的数据，那么在事务 B 中后面无论多少次 select 都只能读到 A commit 之前的数据。但是问题又来了：
- 这次 A 不是 update 了，而是 insert，B select 也不是单条了，而是 select range；
- B 在 A commit 前后两次 select range 会发现结果的数量不一至；这就是幻读；
InnoDB 针对幻读也做了处理：MVCC，在每一行后都有隐藏的两列版本号来实现；大致与处理不可重复读相同；
不可并发带来的问题
Mysql 用串行来实现不可并发，虽说是串行，但是要保证事务被正确的放入串行队列中，就会引入锁等机制，增加了开销，所以非不得已，将不会使用此级别。
三岁于辛 的博客《Mysql学习笔记：事务隔离级别》
