MySQL中的并发控制概览

毫无疑问，并发控制方向的内容是我们学习的重点和难点，在一段时间的学习之后，通常会有一些挫败感，这是一种似懂非懂的感觉，主要的原因其实细究起来理解为：使用并发时需要解决的问题有多个，而要实现并发的方案有多种，它们两者之间没有明显的映射关系，如下图所示。

 

 

 

 

接下来我们来聊一下对于并发控制的理解，首先需要明确一个问题，那就是为什么需要事务。

• 为什么需要事务

为什么需要事务，听起来是个多余的问题，究其原因，事务处理机制，要保证用户的数据操作对数据是“安全”的，比如我们要守护的银行卡余额，我们希望对它的操作是稳定准确，而且绝对是安全的。

那么什么样的操作才是安全的呢，这就引出了事务的ACID特性，ACID的解释和说明如下所示。

ACID特性

解释

原子性（atomicity）

一个事务要么全部执行，要么完全不执行

一致性（consistency）

事务在开始和结束时，应该始终满足一致性约束

隔离性（isolation）

在事务操作时，其他事务的操作不能影响到当前的事务操作

持久性（durability）

事务操作的结果是具有持久性的

这个理解起来就相对简单了，比如我去ATM机取款，要么成功，要么提示余额不足（原子性），比如我取了1000元，那么从ATM里面取出的也应该是1000元，不多不少（一致性），我取款的时候有人给我转账，我不应该拒绝这样的操作（隔离性），取款完毕，我们可以打一张回执单，上面会有我们的余额（持久化），之后查多少次都不会变。

顺着这个思路来看，我们把查询余额看做是读操作，存钱，取款看做是写操作，很多读写操作的并发都相对容易理解了。

对于这样的操作我们分为读和写，它有如下两种组合：

（1）读-读操作

（2）读-写操作

其中我们经常听到的脏读，不可重复读，幻读都是在读-写操作中出现的概念，我们可以用下面的三句话来概括：

l 写在前，读在后：脏读

l 读在前，写在后：不可重复读

l 读在前，写在后，然后又读：幻读

我们可以假设生活中的几个场景，来吃透这三种不是很容易理解的概念，我们就以购物车为例吧，故事的背景是一对情侣，某天早上女生上班前对男生说，帮我关一下电脑，男生关电脑时发现桌面首页显示女生的账号登录了一个购物网站，购物车里有一个化妆品套装，但是还没有下单如下图所示：

 

 

 

l 1）男生说原来不是关电脑这么简单啊，于是就默默下单提交了，这种情况就是脏读，事务B读到了事务A未提交的数据状态。

l 2）男生想多大点事，一套不够，再买一套，于是点击添加了一套，结果女生下班后，带着期待的心情打开购物车，发现化妆品没变，但是数量是2套，这就是不可重复读，重点在于修改，一个事务前后两次读取的结果值并不一致，导致了不可重复读，面对的是相同的查询数据，类似 product_code=’化妆品套装’

l 3）男生明白了，查看了女生浏览的其他几款化妆品，把它们都加入了购物车，结果女生下班后，查看购物车，发现除了之前的那款化妆品，一下子又多了好几款其他的化妆品套装，明明只中意了一款啊，这种情况就是幻读，幻读面对的是一类数据，在这里就是以购物车里的所有商品作为参考。

我们简单总结下，不可重复读和幻读有些类似：一个事务多次读取某条数据，发现读取的数据不完全相同 ，

两者的不同点在于，不可重复读针对数据的修改造成的读不一致，而幻读针对数据的插入和删除造成的读不一致，如同发生幻觉一样。

 

• MySQL并发控制技术方案

数据库的一个核心方向就是并发控制了，并发是对临界资源进行操作，通过并发控制技术来确保整个过程中对于数据的操作是“安全”的。

总体来说，有以下的两类并发控制技术：锁机制 (Locking)和多版本并发控制（MVCC）

（1）锁机制 (Locking)

通过锁机制可以保证数据一致性，整体的场景感觉无非是读-读，读-写，写-写这几类并发，看起来容易，但是融合到业务场景中是千差万别，相对是比较复杂的。

（2）多版本并发控制（MVCC）

MVCC(Multiversion Concurrency Control)是侧重于读写并发的改善机制，它可以避免写操作堵塞读操作的并发问题，通过使用数据的多个版本保证并发读写不冲突的一种机制，它只是一种标准，并不是规定了明细的实现细节，所以在数据库方向上大体会有一些MVCC的不同实现。

写-写的场景其实相对容易理解，为了保证在同一时间完成数据的一致性操作，我们需要通过锁的方式来控制，为了方便理解，整个过程简单理解是串行的，有一些改进的细节我们在后面会说。

这里要先引出一个概念，就是2PL(Two-Phase Locking ，二阶段锁），这个过程我们举个例子就很容易理解了。加锁阶段只加锁，解锁阶段只放锁，就好像我们呼吸一样，吸气，呼气，一张一弛，但是不会彼此交叉。把这个过程细化到一个数据并发中的场景：

（1） 操作数据前，加锁，互相排斥，不允许其他并发任务操作。

（2） 操作数据后，解锁，其他任务可以继续执行。

这种锁定的方式相对比较单一而且粒度太粗，这样会导致在并发读任务都会阻塞，对于并发的性能影响是很大的，所以InnoDB实现了两种类型的行锁。

l 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同的数据集的排他锁。

l 排他锁（X）：允许获得排他锁的事务更新数据，但是组织其他事务获得相同数据集的共享锁和排他锁。

简单小结为：

l 共享锁（S）之间不互斥，读读操作可以并行。

l 排它锁（X）是互斥关系，读写，写写操作不可以并行。

一些常见的共享锁的使用方式有：

共享锁：

select * from table_name where .....lock in share mode

排他锁：

select * from table_name where .....for update

通过这一层的改进，可以对于读读并发的场景有了较好的支撑，但是写入的过程中，读任务还是会被阻塞，对于读写的操作还是存在瓶颈，所以在这个层面上引入了MVCC，在详细展开之前，我们需要了解下MVCC并发控制中的两类读操作，快照读（Snapshot Read）和当前读(Current Read),其中快照读读取的是数据的可见版本，可能是数据的历史镜像，这个过程是不加锁的，而当前读读取的是最新的版本，会加上锁，保证其他事务不会再修改这条记录。

比如我们触发了一条select操作: select * from test where id=100; id为主键，这条语句对应的操作就是快照读，而我们上面刚刚列举的共享锁和排它锁的SQL还有常见的DML都属于当前读，操作过程中会读取当前最新的版本，保证其他事务不能修改当前记录。

我们通过思维导图的形式简单对并发控制技术做个总结，如下图所示。