MySQL 中的锁（一）_代码007(未授权)

本文介绍: 我们说幻读问题的产生是因为当前事务读取了一个范围的记录，然后另外的事务向该范围内插入了新记录，当前事务再次读取该范围的记录时发现了新插入的新记录，我们把新插入的那些记录称之为幻影记录。有的时候楼层会进行检修，比方说换地板，换天花板，检查水电啥的，这些维修项目并不能同时开展。不可重复读的产生是因为当前事务先读取一条记录，另外一个事务对该记录做了改动之后并提交之后，当前事务再次读取时会获得不同的值，如果在当前事务读取记录时就给该记录加锁，那么另一个事务就无法修改该记录，自然也不会发生不可重复读了。

按照 MySQL 官方的说法，InnoDB 中锁可以分为：
在这里插入图片描述
可见，InnoDB 中锁非常多，总的来说，可以如下分类：

这些锁都是做什么的？具体含义是什么？我们现在来一一学习。

我们已经知道事务并发执行时可能带来的各种问题，最大的一个难点是：一
方面要最大程度地利用数据库的并发访问，另外一方面还要确保每个用户能以一
致的方式读取和修改数据，尤其是一个事务进行读取操作，另一个同时进行改动
操作的情况下。

一个事务进行读取操作，另一个进行改动操作,我们前边说过，这种情况下
可能发生脏读、不可重复读、幻读的问题。
SQL 标准规定不同隔离级别下可能发生的问题不一样：
在 READ UNCOMMITTED 隔离级别下，脏读、不可重复读、幻读都可能发生。
在 READ COMMITTED 隔离级别下，不可重复读、幻读可能发生，脏读不可以发生。
在 REPEATABLE READ 隔离级别下，幻读可能发生，脏读和不可重复读不可以发生。
在 SERIALIZABLE 隔离级别下，上述问题都不可以发生。
不过各个数据库厂商对 SQL 标准的支持都可能不一样，与 SQL 标准不同的一
点就是，MySQL 在 REPEATABLE READ 隔离级别实际上就基本解决了幻读问题。
怎么解决脏读、不可重复读、幻读这些问题呢？其实有两种可选的解决方案：

所谓的 MVCC 我们在前一章有过详细的描述，就是通过生成一个 ReadView，
然后通过 ReadView 找到符合条件的记录版本（历史版本是由 undo 日志构建的），
其实就像是在生成 ReadView 的那个时刻做了一个快照，查询语句只能读到在生
成 ReadView 之前已提交事务所做的更改，在生成 ReadView 之前未提交的事务或
者之后才开启的事务所做的更改是看不到的。而写操作肯定针对的是最新版本的
记录，读记录的历史版本和改动记录的最新版本本身并不冲突，也就是采用
MVCC 时，读-写操作并不冲突。

我们说过普通的 SELECT 语句在 READ COMMITTED 和 REPEATABLE READ 隔离
级别下会使用到 MVCC 读取记录。在 READ COMMITTED 隔离级别下，一个事务
在执行过程中每次执行 SELECT 操作时都会生成一个 ReadView，ReadView 的存在
本身就保证了事务不可以读取到未提交的事务所做的更改，也就是避免了脏读现
象；REPEATABLE READ 隔离级别下，一个事务在执行过程中只有第一次执行
SELECT 操作才会生成一个 ReadView，之后的 SELECT 操作都复用这个 ReadView，
这样也就避免了不可重复读和很大程度上避免了幻读的问题。

事务利用 MVCC 进行的读取操作称之为一致性读，或者一致性无锁读，也称
之为快照读，但是往往读取的是历史版本数据。所有普通的 SELECT 语句（pla in
SELECT）在 READ COMMITTED、REPEATABLE READ 隔离级别下都算是一致性读。
上面的这句话中，普通的 SELECT 语句是指不加锁的 select 语句在非串行化事务隔离级别下。