Mysql笔记：事务隔离级别理解

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

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

并发事务带来的问题

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

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

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

脏读

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

   不可重复读

   知道了脏读的原因后，为了解决这个问题，Mysql 规定 B 读的数据只能读取已经 commit 状态的数据：
4. A begin => update 后让 cpu
5. 同时 B begin => select，这次 B 很小心地验证 A 的数据是否 commit 了，B 这次读到了 A begin 以前的数据；
6. 事务 A 在下一个 cpu 时间又得到了调度，A commit 了；
7. B 再次 select，但是已经 select 到了 A commit 后的数据了，B 在 A commit 前后读到了两次不一样的数据，即不可重复读了；

   幻读

   知道了不可重复读的原因后，Mysql 又规定，既然 B 第一次读到的是 A commit 前的数据，那么在事务 B 中后面无论多少次 select 都只能读到 A commit 之前的数据。但是问题又来了：
8. 这次 A 不是 update 了，而是 insert，B select 也不是单条了，而是 select range；
9. B 在 A commit 前后两次 select range 会发现结果的数量不一至；这就是幻读；

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