inndb 读大量数据时会加读锁么?

Posted Ever-Lose 的博客

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了inndb 读大量数据时会加读锁么?相关的知识,希望对你有一定的参考价值。

结论

默认不会加读锁!但 mysql InnoDB 的可重复读并不保证避免幻读,需要应用使用加锁读来保证。而这个加锁度使用到的机制就是 next-key locks。

隔离级别说明

MySQL InnoDB事务的隔离级别有四级,默认是“可重复读”(REPEATABLE READ)。

  • 未提交读(READ UNCOMMITTED)。另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据(脏读)。
  • 提交读(READ COMMITTED)。本事务读取到的是最新的数据(其他事务提交后的)。问题是,在同一个事务里,前后两次相同的SELECT会读到不同的结果(不重复读)。
  • 可重复读(REPEATABLE READ)。在同一个事务里,SELECT的结果是事务开始时时间点的状态,因此,同样的SELECT操作读到的结果会是一致的。但是,会有幻读现象(稍后解释)。
  • 串行化(SERIALIZABLE)。读操作会隐式获取共享锁,可以保证不同事务间的互斥。

四个级别逐渐增强,每个级别解决一个问题。

  • 脏读,最容易理解。另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据。
  • 不重复读。解决了脏读后,会遇到,同一个事务执行过程中,另外一个事务提交了新数据,因此本事务先后两次读到的数据结果会不一致。
  • 幻读。解决了不重复读,保证了同一个事务里,查询的结果都是事务开始并且第一次查询时的状态(一致性)。但是,如果另一个事务同时提交了新数据,虽然本事务再次按照相同的条件查找会得到相同的结果集,但是本事务指定更新时,就会“惊奇的”发现了这些新数据,貌似之前读到的数据是“鬼影”一样的幻觉。

所以 InnoDB 默认还是会出现幻读现象的,所以还是可能会加锁。

幻读的演示

摘自 CSDN博主「南C哥」-MySQL中幻读现象

银行A开启了一个事务窗口,查询当前系统中有没有"wangwu"用户,发现没有,银行B也开启了一个事务窗口,查询当前系统中也没有"wangwu"用户,银行A先创建"wangwu"用户并且提交,由于可重复读取,银行B在一次事务中必须保证查询的数据一致性,因此查询不到"wangwu",结果银行B窗口认为wangwu没有被注册想注册"wangwu"用户,就创建"wangwu"用户结果发现系统提示"wangwu"用户已经被注册",但是在本次事务中又查询不到"wangwu",就好像出现幻觉一样

create table user(
  id int primary key,
  username varchar(30),
  money double
);
insert into user values(1,\'zhangsan\',100);
insert into user values(2,\'lisi\',100);

打开两个MySQL窗口

image

解决幻读可以提高事务隔离级别为 Serializable (串行化),它是使用的共享锁,当然 MySQL 有锁的类型:共享锁(S)、排他锁(X)、意向共享(IS)、意向排他(IX)。 还有非锁定读:不需要等待访问行上的锁释放,读取行的一个快照。

具体参照 Innodb锁机制:Next-Key Lock 浅谈

以上是关于inndb 读大量数据时会加读锁么?的主要内容,如果未能解决你的问题,请参考以下文章

一步一步实现读写锁

golang读写锁实现与核心原理分析

数据库的读锁和写锁在业务上的应用场景总结

线程锁相关,锁消除,锁相关

Mysiam锁模式 innodb锁模式 是什么区别

ReentrantReadWriteLock场景应用