MVCC 英文全称为Multi-Version Concurrency Control,翻译为中文即 多版本并发控制。实现非堵塞式并发访问。这个原理有点类似《Java里面的CAS实现原理》谁像谁说不定类比来学吧
- 事务隔离级别
脏写：一个事务修改了另一个未提交事务修改过的数据，也就是区修改别人未提交的部分当回滚时就修改不复存在了。
脏读：一个事务读到了另一个未提交事务修改过的数据，同样的回滚时就读取到了一个不存在的数据，
不可重复读：就是说一个事务没有提交的时候读取了另一个数据，读取之后这个数据被另外一个事务给修改了，当这个未提交的事务再次读取该数据时和之前的不一样了。这就发生了不可重复读，就是在同一事务读取多次的值不一样。
幻读：和不可重复读类似，不过是两次读取的记录数量不一样，像幻影般突然的出现。
SQL标准的隔离级别如下：
| 隔离级别 | 名称 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|---|
| READ UNCOMMITTED | 未提交读 | Possible | Possible | Possible |
| READ COMMITTED | 已提交读 | Not Possible | Possible | Possible |
| REPEATABLE READ | 可重复读 | Not Possible | Not Possible | Possible |
| SERIALIZABLE | 可串行化 | Not Possible | Not Possible | Not Possible |
不出现脏写是因为，所有隔离级别都不允许出现脏写。
- MySQL的隔离级别
不同的数据库支持标准SQL的隔离级别是不一样的，MySQL四种隔离级别都支持，且MySQL的默认隔离级别为REPEATABLE READ，我们可以手动修改一下事务的隔离级别。而且MySQL在REPEATABLE READ隔离级别下，是可以禁止幻读问题的发生的。
1、使用READ UNCOMMITTED隔离级别的事务，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了
2、对于使用SERIALIZABLE隔离级别的事务来说，设计者规定使用加锁的方式来访问记录
3、对于使用READ COMMITTED和REPEATABLE READ隔离级别的事务来说，都必须保证读到已经提交了的事务修改过的记录，也就是说假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是：需要判断一下版本链中的哪个版本是当前事务可见的， - readview
readview保存当前活跃的读写事务ID、当前活跃的最小事务ID、下一个即将生成的事务ID（通过生成事务的那个全局变量预测）、生成该readview的事务ID。有了这个readview，当要访问一个记录时先判断该记录的隐藏列中有一个事务ID，即修改该记录的事务ID，如果小于且不在活跃readview里的活跃列表，说明事务已经提交了就可以直接访问，如果还在活跃列表里就说明还在活跃不可以读取否则就脏读。如果大于就说明生成readview后才生成的事务是不可访问否则会出现不可重复读或幻读。当不可访问时即会获取隐藏列里的回滚指针找到undo日志然后继续对比直到可以访问或者版本链的结尾为止。《版本链是啥》 - RC和RR隔离级别的不同实现
READ COMMITTED —— 每次读取数据前都生成一个ReadView
也就是说事务里面有多次读取操作的话，每次读取都会生成一个ReadView快照，也就是说上一次读取的时的ReadView和本次读取的可能不一样，所以可能会读到不一样的版本也就是不可重复读或幻读
REPEATABLE READ —— 在第一次读取数据时生成一个ReadView
也就是说事务一旦开始，第一次查询和同一个事务中的第几次查询都是同一个ReadView，也就是版本定格快照在开启事务那个刻，以后每次读取到的版本都一样，也即是不会发生不可重复读或幻读
脏读都不可能发生，因为这两种读取都在事务活跃的版本不可读的，也就是只能读取到已经提交的事务的版本。所以不可能脏读。
这个原理有点类似《Java里面的CAS实现原理》谁像谁说不定类比来学吧
- 思考
会发现MVCC好啊，不会堵塞，但是发现只是解决了读的问题，写入没法保证，怎么避免不会发生脏写呢，当然是通过锁的方式来了，修改一个记录前先锁住不给其他事务修改也就是不会发生脏写了。还有一个问题，当某个业务需要每次都要读到最新的值咋办这个MVCC读到的可能是旧版本，这需求当然也是通过锁来搞定了读写都锁就对了。还有就是明白一个是，常规的查询语气中不会加锁，除非显式的写加锁，常规不做其他声明的写语气中会加锁保证不会发生脏锁，，，，锁的详细内容
转至《MySQL——锁机制简述》