最后我们学习一下最高的事务隔离级别Serializable,顾名思义,可串行化的,也即并发事务串行执行。很显然,该级别可以避免前面讲到的所有问题:“脏读”、“不可重复读”和“幻读”。代价是处理事务的吞吐量低,严重浪费数据库的性能,因此要慎用此事务隔离级别。
下面演示Serializable如何解决这些问题:
1. 小明连接数据库去查询自己本学期的成绩,他设置session(当前连接)的事务隔离级别为Serializable:
xiaoming> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)
xiaoming> select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| SERIALIZABLE |
+----------------+
1 row in set (0.00 sec)
2. 小明开始查询成绩,由于还没有录入,因此没有成绩:
xiaoming> begin;
Query OK, 0 rows affected (0.00 sec)
xiaoming select * from scores where name = 'xiaoming';
Empty set (0.00 sec)
3. 这时小明的班主任王老师也连接数据库来录入成绩,可是他会卡在插入第一条成绩信息这里, 如下所示,insert语句迟迟不会返回:
mr.wang> begin;
Query OK, 0 rows affected (0.00 sec)
mr.wang> insert into scores(name, score) values ('xiaoming', 69);
4. 小明结束本次查询:
xiaoming> commit;
Query OK, 0 rows affected (0.00 sec)
5. 这时王老师插入第一条成绩才完成:
mr.wang> insert into scores(name, score) values ('xiaoming', 69);
Query OK, 1 row affected (3.42 sec)
6. 如果小明久久不结束查询,还会导致王老师录入成绩超时:
xiaoming> insert into scores(name, score) values ('xiaoming', 69);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
从上面的例子我们可以看出,如果一个session设置隔离级别为Serializable时,其执行事务时会阻塞其他并发事务,从上面的错误信息中我们也可以看出应该是通过某种锁来实现的。既然是这样,那么“脏读”、“不可重复读”和“幻读”自然是不可能发生了。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)