游戏网站模板源码,成都开网站,wordpress 三合一,抖音开放平台游戏这是一篇数据库隔离级别的科普文章#xff0c;旨在了解数据库中著名的幻读现象#xff0c;为了专注#xff0c;对脏读、不可重复读不作讨论。
事务隔离级别
MySQL有四级事务隔离级别: 读未提交 READ-UNCOMMITTED#xff1a; 存在脏读#xff0c;不可重复读#xff0c;幻…这是一篇数据库隔离级别的科普文章旨在了解数据库中著名的幻读现象为了专注对脏读、不可重复读不作讨论。
事务隔离级别
MySQL有四级事务隔离级别:
读未提交 READ-UNCOMMITTED 存在脏读不可重复读幻读的问题 读已提交 READ-COMMITTED不存在脏读但存在不可重复读幻读问题 可重复读 REPEATABLE-READ不存在脏读不可重复读问题但存在幻读问题 序列化SERIALIZABLE解决脏读不可重复读幻读问题但完全串行执行性能最低什么是幻读
幻读错误的理解说幻读是事务A 执行两次 select 操作得到不同的数据集即 select 1 得到10条记录select 2 得到11条记录。这其实并不是幻读这是不可重复读的一种只会在 R-U R-C 级别下出现而在 mysql 默认的 RR 隔离级别是不会出现的。
这里给出我对幻读的理解
幻读并不是说事务中多次读取获取的结果集不同幻读更重要的是某次的 select 操作得到的结果集所表征的数据状态无法支撑后续的业务操作。更为具体一些select 记录不存在准备插入此记录但执行 insert 时发现此记录已存在无法插入如同产生了幻觉举个例子可能会简化理解
mysql show create table user\G
*************************** 1. row ***************************Table: user
Create Table: CREATE TABLE user (id int(11) NOT NULL,name varchar(32) DEFAULT NULL,PRIMARY KEY (id)
) ENGINEInnoDB DEFAULT CHARSETutf8分别开启两个事务T1 T2并设置其隔离级别为Reaptable-Read
T1
mysql set global transaction isolation level repeatable read;
mysql begin;
mysql select * from user;
mysql insert into user values (1, jeff);
ERROR 1062 (23000): Duplicate entry 1 for key PRIMARY
mysql select * from user;
T2:
mysql set global transaction isolation level repeatable read;
mysql begin;
mysql insert into user values (1, jeff);
mysql commit;
T1 事务检测表中是否有 id 为 1 的记录没有则插入
T2 插入干扰记录造成T1出现幻读。
上例中需要确保T1事务执行begin后才开始执行事务T2。
上例中T1就发生了幻读因为 T1读取的数据状态与后面的动作发生了语义上的冲突查询的时候明明提示记录不存在插入的时候去提示主键重复类似于出现幻影因而称之为幻读。
如何消除幻读
MySQL当前有两种方式可以消除幻读
1. 通过对select操作手动加行X锁(SELECT ... FOR UPDATE )。原因是InnoDB中行锁锁定的 是索引纵然当前记录不存在当前事务也会获得一把记录锁记录存在就加行X锁不 存在就加next-key lock间隙X锁这样其他事务则无法插入此索引的记录杜绝幻 读。 2. 进一步提升隔离级别为SERIALIZABLE测试一下效果
mysql begin;
mysql select * from user where id 2 for update;
mysql insert into user values (2, tony);mysql commit;
T2:
mysql begin;
mysql insert into user values (2, jimmy);
ERROR 1062 (23000): Duplicate entry 2 for key PRIMARY
现在T1查询时携带了for update在Innodb内会对该索引加锁即使当前不存在于是事务T2的insert会被阻塞直到T1显示提交这样T1成功了对于T1来说幻读确实被消除了但T2的插入会报主键重复这也符合预期。
至于另外一种提升隔离级别消除幻读的方式感兴趣的可以自己尝试这里不再重复其本质是类似的只是让系统代替了手工加锁。
总结
RR作为 mysql 事务默认隔离级别是事务安全与性能的折中正确认识幻读后开发者便可以根据需求自行决定是否需要防止幻读。
SERIALIZABLE则是悲观的认为幻读时刻都会发生故会自动的隐式的对事务所需资源加排它锁其他事务访问此资源会被阻塞等待故事务是安全的但需要认真考虑性能。
InnoDB的锁是针对索引这点需要引起注意。对行记录加锁如果存在加X锁否则会加 next-key lock / gap 锁 / 间隙锁故InnoDB可以实现事务对某记录的预先占用只要本事务还在其他事务就别想占有它。
