隔离级别和MVCC

-----本文章为个人理解,如有疑问或错误欢迎留言并讨论-----

谢谢。


昨天去去哪儿网面试,老周和老赵问了很多问题,大多关于细节,其中就包括事务隔离级别和MVCC,由于准备不够充分,所以今天特地进行验证。

其中隔离级别中,比较让人难以理解的是repeatable read可重复读,和serializable串行读,下面依次进行试验,查看彼此区别。


serializable隔离级别:

session 1 session 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 1 session 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完是由锁来控制,所有事务均符合锁特征。


以下内容摘自:http://www.blogjava.net/neverend/archive/2012/04/05/373357.html

在事务隔离级别设定为repeatable read的情况下,一般的select语句采取的是一致性非阻塞读的方式。
一致性是指在事务的范围内读取的数据是可重现的,不会出现不可重复读的情况。非阻塞是指这种读取数据的模式不会对数据上任何一种锁,其它操作全都不会被阻塞。
在这种模式下,事务执行读取语句后,相关的数据会有一套副本出现,并会为这个数据副本附加一个时间戳,其它事务在这个时间戳之后执行的写操作都不会反映到这个副本中,这种机制被称之为多版本并发控制。
如果用select …… lock in share mode,则不是一致性非阻塞读,该语句会等待其它事务的写语句提交或回滚之后再读取数据;如果事务隔离级别设置为read committed,也不是一致性非阻塞读,该语句会读取其它事务提交的数据。

你可能感兴趣的:(mvcc,隔离级别)