-----本文章为个人理解，如有疑问或错误欢迎留言并讨论-----
谢谢。
昨天去去哪儿网面试，老周和老赵问了很多问题，大多关于细节，其中就包括事务隔离级别和MVCC，由于准备不够充分，所以今天特地进行验证。
其中隔离级别中，比较让人难以理解的是repeatable read可重复读，和serializable串行读，下面依次进行试验，查看彼此区别。
serializable隔离级别：session 1session 2
mysql> show variables like '%iso%';
+---------------+--------------+
| Variable_name | Value |
+---------------+--------------+
| tx_isolation | SERIALIZABLE |
+---------------+--------------+
1 row in set (0.00 sec)
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from t;
+---+
| i |
+---+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+---+
5 rows in set (0.00 sec)mysql> show variables like '%iso%';
+---------------+--------------+
| Variable_name | Value |
+---------------+--------------+
| tx_isolation | SERIALIZABLE |
+---------------+--------------+
1 row in set (0.00 sec)
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from t;
+---+
| i |
+---+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+---+
5 rows in set (0.00 sec)
mysql> insert into t values (6);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> insert into t values (10);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
上面现象说明：当隔离级别为serializable的时候，不兼容MVCC，严格遵循锁机制，当session1 和session2都进行全表查询时，两个会话都会全表加读锁，由于读锁只和读锁相兼容，所以此时任何一个会话都无法修改、插入数据，会进入所等待。
repeatable read隔离级别：
session 1session 2
mysql> show variables like '%iso%';
+---------------+-----------------+
| Variable_name | Value|
+---------------+-----------------+
| tx_isolation | REPEATABLE-READ |
+---------------+-----------------+
1 row in set (0.00 sec)
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from t;
+---+
| i |
+---+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+---+
5 rows in set (0.00 sec)mysql> show variables like '%iso%';
+---------------+-----------------+
| Variable_name | Value|
+---------------+-----------------+
| tx_isolation | REPEATABLE-READ |
+---------------+-----------------+
1 row in set (0.00 sec)
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from t;
+---+
| i |
+---+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+---+
5 rows in set (0.00 sec)
mysql> insert into t values (6);
Query OK, 1 row affected (0.00 sec)
mysql> select * from t;
+---+
| i |
+---+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
+---+
6 rows in set (0.00 sec)mysql> select * from t;
+---+
| i |
+---+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+---+
5 rows in set (0.00 sec)
mysql> insert into t values (6);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
上面现象说明：当隔离级别为repeatable read时，兼容使用MVCC(使用undo)，此时两个事物读取数据到各自的undo中，事物之间独立，但是不同事务对于同一行数据的修改会根据顺序加上排他锁。其中上面session 2最后插入一条数据，是因为session 1已经存在并将该行数据锁定，同时此刻出现在repeatable read隔离级别所特有的幻读现象(本会话内并没有该数据，却依然无法插入)。
总结：
MVCC：多版本控制，多个未提交事务所看到的数据都是自己的，彼此不同，在客户端总体看来仿佛多个版本个数据库。
MVCC只和隔离级别read-committed和repeatable-read相兼容，MACC对于不同事物的同一行的读写之间是不加锁的，对于不同事务的同一行的写写加锁。
MVCC和read-uncommitted和serializable不兼容，其中serializable完是由锁来控制，所有事务均符合锁特征。
在事务隔离级别设定为repeatable read的情况下，一般的select语句采取的是一致性非阻塞读的方式。一致性是指在事务的范围内读取的数据是可重现的，不会出现不可重复读的情况。非阻塞是指这种读取数据的模式不会对数据上任何一种锁，其它操作全都不会被阻塞。在这种模式下，事务执行读取语句后，相关的数据会有一套副本出现，并会为这个数据副本附加一个时间戳，其它事务在这个时间戳之后执行的写操作都不会反映到这个副本中，这种机制被称之为多版本并发控制。如果用select …… lock in share mode，则不是一致性非阻塞读，该语句会等待其它事务的写语句提交或回滚之后再读取数据；如果事务隔离级别设置为read committed，也不是一致性非阻塞读，该语句会读取其它事务提交的数据。
如果觉得《mysql mvcc 隔离级别_隔离级别和MVCC》对你有帮助，请点赞、收藏，并留下你的观点哦！
