MySQL并发控制

并发即指在同一时刻，发控多个操作并行执行。发控MySQL对并发的发控处理主要应用了两种机制——是“锁”和“多版本控制”。

锁

锁分为读锁和写锁两种，发控也称作共享锁和排他锁。发控

因为多个读操作同时进行是发控不会破坏数据的，所以读锁是发控共享的，多个读操作可以同时进行，发控互不干扰。发控

为了防止多个写操作共同执行破坏数据，发控写锁是发控排他的，一个写锁会阻塞其它的发控写锁和读锁，进而保证同一资源在任何时刻只有一个写操作在执行，发控并防止其它用户读取正在写入的发控该资源。

在锁粒度方面，发控MySQL包括表锁和行锁两种类型。锁的粒度越小，越有利于对数据库操作的并发执行。但是管理锁消耗的资源也会更多。如果系统花费大量的云服务器提供商时间来管理锁，而不是存储数据，那么系统的性能也会受到影响。

表锁会锁定整张表，它是开销最小的策略。诸如ALTER TABLE之类的语句会使用表锁。

行锁***程度的支持并发操作，同时也带来了***的开销。InnoDB实现了行锁。

在MySql中并不只是用锁来维护并发控制。

事务的隔离级别

事务的概念在此不多介绍。我觉得，也可以将事务看成是并发中的一部分——事务包含了一组操作，事务和事务之间可以并行执行。事务和事务之间的并发也和普通的并发操作一样会共享相同的资源，这样并发执行的事务之间就会相互影响。根据事务之间影响程度的b2b供应网不同，提出了事务的隔离级别这个概念，分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE。

READ UNCOMMITTED就是一个事务对共享数据的修改马上就能够被另一个事务感知到，其实也就是没有对修改操作做任何特殊处理。

SERIALIZABLE是通过加锁的方式强制事务串行执行，这样可以避免幻读。但这种方式会带来大量锁争用问题。

READ COMMITTED和REPEATABLE READ是基于MVCC的方式实现的。

MVCC多版本并发控制

MySql对于事务之间并发控制的实现并不是简单的使用行级锁。MySql在读操作时并不加锁，只有在写操作时才会对修改的资源加锁。

MVCC保存了数据资源在不同时间点上的多个快照。根据事务开始的时间不同，站群服务器每个事务看到的数据快照版本是不一样的。

InnoDB中的MVCC实现：存储引擎全局维护了一个系统版本号，每开启一个新的事务，这个系统版本号就会递增。事务开始时刻的系统版本号，会作为这个事务本身的版本号。在每行记录中，存储引擎又在每行的后面保存两个隐藏的列，分别保存这一行的开始版本号和过期版本号。在REPEATABLE READ隔离级别下，MVCC的具体操作如下：

INSERT

存储引擎为新插入的每一行保存当前的系统版本号作为这一行的开始版本号。

UPDATE

存储引擎会新插入一行记录，当前的系统版本号就是新记录行的开始版本号。同时会将原来行的过期版本号设为当前的系统版本号。

DELETE

存储引擎将删除的记录行的过期版本号设置为当前的系统版本号。

SELECT

当读取记录时，存储引擎会选取满足下面两个条件的行作为读取结果。

1. 读取记录行的开始版本号必须早于当前事务的版本号。也就是说，在当前事务开始之前，这条记录已经存在。在事务开始之后才插入的行，事务不会看到。

2. 读取记录行的过期版本号必须晚于当前事务的版本号。也就是说，当前事务开始的时候，这条记录还没有过期。在事务开始之前就已经过期的数据行，该事务也不会看到。

通过上面的描述，可以看到在存储引擎中，同一时刻存储了一个数据行的多个版本。每个事务会根据自己的版本号和每个数据行的开始及过期版本号选择读取合适的数据行。

MVCC只在READ COMMITTED和REPEATABLE READ这两个级别下工作。

很赞哦!（59）