初步结论:
1.数据库隔离级别是为了有效的控制并发读取数据的正确性。
2.事务隔离级别大致可按照如下四大需求定义:可读未提交数据、只能读已提交的数据、提交了的数据也不能读(存在例外)、提交了的数据绝对读不到(因为是串行提交的)
零碎知识点
- 数据库使用两阶段锁:加锁阶段、解锁阶段
- 两类锁:共享锁、排它锁。共享锁可以叠加共享锁,不能叠加排它锁;排它锁不能叠加任何其它的锁
- 查询操作是带共享锁的,在READ UNCOMMITTED、READ COMMITED级别查询完后释放了共享锁,不用等待commit来释放共享锁,REPEATABLE READ、SERIALIZABLE级别会在commit时释放共享锁(可由下面测试结果验证)
事务 | 加锁/解锁处理 |
---|---|
begin; | |
insert into test ..... | 加insert对应的锁 |
update test set... | 加update对应的锁 |
delete from test .... | 加delete对应的锁 |
commit; | 事务提交时,同时释放insert、update、delete对应的锁 |
MySQL版本及引擎
SELECT VERSION(); -- 输出:5.7.12-log
测试表结构
CREATE TABLE `user` (
`userId` varchar(20) NOT NULL COMMENT '用户ID',
`userName` varchar(20) DEFAULT NULL COMMENT '用户名称',
PRIMARY KEY (`userId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
事务隔离级别:READ UNCOMMITTED(可读未提交数据)
会话一:
SET session transaction isolation level READ UNCOMMITTED; --
REPEATABLE READ
BEGIN;
SELECT SLEEP(10);
SELECT * FROM `user`; -- 能够查询到会话二插入的数据
COMMIT;
会话二:
SET session transaction isolation level READ UNCOMMITTED; --
READ UNCOMMITTED、REPEATABLE READ
BEGIN;
INSERT `user` VALUES('1', 'username1');
SELECT SLEEP(10);
COMMIT;
事务隔离级别:READ COMMITTED(只能读已提交的数据)
会话一:
SET session transaction isolation level READ COMMITTED;
BEGIN;
SELECT * FROM `user`; -- 查询到以前的数据
SELECT SLEEP(10);
SELECT * FROM `user`; -- 查询到以前的数据(验证查询不到未提交的数据)
SELECT SLEEP(10);
SELECT * FROM `user`; -- 能查询到会话二新增的数据(验证能查询到已提交的数据)
COMMIT;
会话二:
SET session transaction isolation level READ COMMITTED;
BEGIN;
INSERT `user` VALUES('2', 'username2');
SELECT SLEEP(10);
COMMIT;
事务隔离级别:REPEATABLE READ(提交了的数据也不能读(存在例外)
会话一:
SET session transaction isolation level REPEATABLE READ;
BEGIN;
SELECT * FROM `user`; -- 查询到以前的数据(如果去掉该查询,下一个查询在休眠10s后能获取到会话二变更的数据,验证了查询语句在事务隔离级别为REPEATABLE READ时不会立即释放共享锁,而是在commit;时释放共享锁)
SELECT SLEEP(10);
SELECT * FROM `user`; -- 查询到以前的数据(验证即便其它事务已提交也查询不到数据)
SELECT * FROM `user` FOR UPDATE; -- 能查询到会话二提交的数据(验证存在幻读的情况一)
SELECT * FROM `user`; -- 查询到以前的数据
UPDATE `user` SET userName='nihao'; -- 将会话二提交的数据也更新了(验证存在幻读的情况二)
SELECT * FROM `user`; -- 能查询到更新之后的数据
COMMIT;
会话二:
SET session transaction isolation level REPEATABLE READ;
BEGIN;
INSERT `user` VALUES('3', 'username3');
COMMIT;
疑问:
- 问:既然会话一的查询共享锁要到commit;后才释放,为什么会话二没有等待会话一commit;后再执行插入数据?
答:在RR级别是使用乐观锁来实现的,要用FOR UPDATE或lock in share mode才能按照“当前读”的方式读取数据库中最新数据,否则只能读取到快照中的数据,
MVCC在MySQL的InnoDB中的实现
在InnoDB中,会在每行数据后添加两个额外的隐藏的值来实现MVCC,这两个值一个记录这行数据何时被创建,另外一个记录这行数据何时过期(或者被删除)。 在实际操作中,存储的并不是时间,而是事务的版本号,每开启一个新事务,事务的版本号就会递增。 在可重读Repeatable reads事务隔离级别下:
- SELECT时,读取创建版本号<=当前事务版本号,删除版本号为空或>当前事务版本号。
- INSERT时,保存当前事务版本号为行的创建版本号
- DELETE时,保存当前事务版本号为行的删除版本号
- UPDATE时,插入一条新纪录,保存当前事务版本号为行创建版本号,同时保存当前事务版本号到原来删除的行
事务隔离级别:SERIALIZABLE(提交了的数据绝对读不到(因为是串行提交的))
会话一:
SET session transaction isolation level SERIALIZABLE;
BEGIN;
SELECT * FROM `user`; -- 查询到以前的数据(如果去掉该查询,会话二不会等待再执行,验证了查询语句在事务隔离级别为SERIALIZABLE时才不会立即释放共享锁,而是在commit;时释放共享锁)
SELECT SLEEP(10);
SELECT * FROM `user`; -- 查询到以前的数据
COMMIT;
会话二:
SET session transaction isolation level SERIALIZABLE;
BEGIN;(等待会话一执行完毕后才执行)
INSERT `user` VALUES('4', 'username4');
COMMIT;
网友评论