User表有2条数据
设置隔离级别
-- 设置当前会话的隔离级别,新会话失效
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 设置全局隔离级别,mysql重启后失效
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 查询隔离级别
SELECT @@transaction_isolation;
show variables like '%isolation%';
还有是在my.cnf
文件的[mysqld]
下设置隔离级别,需要重启mysql生效
[mysqld]
transaction-isolation = READ-UNCOMMITTED
transaction-isolation = READ-COMMITTED
transaction-isolation = REPEATABLE-READ
transaction-isolation = SERIALIZABLE
读未提交
数据库transaction_isolation
的隔离级别为READ-UNCOMMITTED
# a1
begin;
# a2
UPDATE `user` SET name = '王五' WHERE id = 1;
# a3
commit;
# b1
begin;
# b2
SELECT * FROM `user` u;
# b3
commit;
在会话b执行b1和b2,开启一个事务,并执行查询操作,得到结果是张三和李四。
在会话a执行a1和a2,开启一个事务,并执行更新操作,这时候不提交,再执行一次b2,再一次查询User表,得到结果是修改后的王五
假设会话a不提交,而是回滚,那会话b第二次读到的是未提交的数据,造成了脏读问题。
读已提交
数据库transaction_isolation
的隔离级别为READ-COMMITTED
# a1
begin;
# a2
UPDATE `user` SET name = '王五' WHERE id = 1;
# a3
commit;
# b1
begin;
# b2
SELECT * FROM `user` u;
# b3
commit;
在会话a先执行a1和a2,开启一个事务,并执行更新操作,这时候不提交,新开一个会话执行b1和b2,得到结果是张三和李四。
执行a3提交会话a的事务,再执行一次b2,再一次查询User表,得到结果是修改后的王五
这里前后执行两次b2的结果是不一致的,所以会有不可重复读的问题。
可重复读
数据库transaction_isolation
的隔离级别为REPEATABLE-READ
开启两个会话a和b
# a1
begin;
# a2
UPDATE `user` SET name = '王五' WHERE id = 1;
# a3
commit;
# b1
begin;
# b2
SELECT * FROM `user` u;
# b3
commit;
在会话a先执行a1和a2,开启一个事务,并执行更新操作,这时候不提交,新开一个会话执行b1和b2,得到结果是张三和李四。
执行a3提交会话a的事务,再执行一次b2,再一次查询User表,得到结果还是张三和李四。
# a1
begin;
# a2
INSERT INTO `user` (name) values('王五');
# a3
commit;
# b1
begin;
# b2
SELECT COUNT(*) from `user` u ;
# b3
commit;
在会话a先执行a1和a2,开启一个事务,并执行新增操作,这时候不提交,新开一个会话执行b1和b2,统计User表,得到结果是2。
执行a3提交会话a的事务,再执行一次b2,再一次统计User表,得到结果还是2。
所以InnoDB在REPEATABLE-READ
隔离级别没有幻读问题
串型化
数据库transaction_isolation
的隔离级别为SERIALIZABLE
开启两个会话a和b
# a1
begin;
# a2
UPDATE `user` SET name = '王五' WHERE id = 1;
# a3
commit;
# b1
SELECT * FROM `user` u;
# b2
begin;
# b3
SELECT * FROM `user` u;
# b4
commit;
在会话a先执行a1和a2,开启一个事务,并执行更新操作,这时候不提交,新开一个会话执行b1做查询,得到结果还是张三和李四。
再执行b2开启事务,执行b3做查询,这时会阻塞住
执行a3提交会话a的事务,b3就会返回结果,并且是修改后的结果
在SERIALIZABLE
隔离级别下,为什么执行b1做查询,得到的结果还是张三?为什么开启事务后执行b3做查询会阻塞,并且返回修改后的结果?
因为InnoDB读不加锁,读写不冲突,读是根据MVCC来读的。SERIALIZABLE
隔离级别,开启事务后执行b3是当前读,也就是会加读锁,a2先操作已经加了写锁,读锁和写锁有冲突,等会话a提交事务释放写锁后,会从b3返回最新数据