普通的 select 语句。
执行方式是生成 readview，直接利用 MVCC 机制来读取，并不会对记录进行加锁。
它是基于多版本并发控制即 MVCC机制，既然是多版本，那么快照读读到的数据不一定是当前最新的数据，有可能是之前历史版本的数据。
如下的操作是快照读：不加锁的 select 操作（事务级别不是串行化，串行化的是当前读）
它读取的记录都是数据库中当前的最新版本，会对当前读取的数据进行加锁，防止其他事务修改数据，这种锁是一种悲观锁。
当前读的规则，就是要能读到所有已经提交的记录的最新值。
如下操作都是当前读：
- select … lock in share mode 当前读，加读锁 ，也叫共享锁
- select … for update 当前读，加写锁，又叫排他锁
- innoDB 里面 update (排他锁)、insert (排他锁)、delete (排他锁)，都会自动给涉及的语句添加写锁。
- 串行化事务的隔离级别
实现方式：next-key（行记录锁+间隙锁）即临键锁，是前开后闭区间。
在可重复读隔离级别下，普通的查询是快照读，是不会看到别的事务插入的数据的。
因此，幻读在“当前读”下才会出现。
幻读：仅专指“新插入的行”。
产生幻读的原因是，行锁只能锁住行，但是新插入记录这个动作，要更新的是记录之间的“间隙”。因此，为了解决幻读问题，InnoDB 引入了新的锁，也就是间隙锁 (Gap Lock)。
间隙锁：锁的就是两个值之间的空隙。
间隙锁就是，在一行行扫描的过程中，不仅将给行加上了行锁，还给行两边的空隙，也加上了间隙锁。数据行是可以加上锁的实体，数据行之间的间隙，也是可以加上锁的实体。
间隙锁和行锁不一样：
- 行锁之间读读不冲突，读写和写写都会冲突，
- 跟间隙锁存在冲突关系的，是“往这个间隙中插入一个记录”这个操作。间隙锁之间都不存在冲突关系。
间隙锁和next-key lock的引入，可以解决幻读的问题
间隙锁的引入，可能会导致同样的语句锁住更大的范围，这其实是影响了并发度的。因为两个同样的间隙锁没有冲突，插入才会有冲突，所以如果 Session A 加了间隙锁，Session B 再加一个同样的间隙锁，此时不管是 Session A 还是 Session B 一旦再有一个和这个间隙锁冲突的插入语句就造成了死锁。所以会影响并发度。
锁的设计是为了保证数据的一致性。而这个一致性，不止是数据库内部数据状态在此刻的一致性，还包含了数据和日志在逻辑上的一致性。
来源地址：https://blog.csdn.net/qingqingxiaocao1989/article/details/125094127
