大多数MySQL的事务性存储引擎,例如InnoDB. Falcon 和PBXT,不是简单地使用行加锁的机制,而是选用一种叫做**多版本并发控制(MVCC, Mutiversion Concurrency Control)**的技术,和行加锁机制关联使用,以应对更多的并发处理问题。MVCC不是MySQL独有的技术,Oracle, PostgreSQL 及其他一些数据库 系统也使用同样的技术。
可以将MVCC设想成一种行级加锁的变形,它避免了很多情况下的加锁操作,大大降低了系统开销。依赖于具体技术实现,它可以在读取期间锁定需要的记录的同时,还允许非锁定读取。
MVCC是通过及时保存在某些时刻的数据快照,而得以实现的。这意味着同一事务的多个实例,在同时运行时,无论每个实例运行多久,它们看到的数据视图是一致的;而同一时间,对于同一张表,不同事务看到的数据却是不同的!如果用户之前对此没有概念,这可能让人有点迷惑,但随若熟悉程度的加深,这个概念也很容易理解。
每种存储引擎实现MVCC的方式是不同的。例如乐观并发控制(Optimistic Concurrency Control).悲观并发控制(Pessimistic Concurrency Control).下面通过描述InnoDB简化版的行为方式,举例说明MVCC的工作原理。
InnoDB通过为每个数据行增加两个隐含值的方式来实现MVCC.这两个隐含值记录了行的创建时间,以及它的过期时间(或者叫删除时间)。每一行都存储了事件发生时的系统版本号(System Version Number),用来替代事件发生时的实际时阀。每一次,开始个新事务时, 版本号都会自 动递增。每个事务都会保存它在开始时的“当前系统版本”的记录,而每个查询都会根据事务的版本号,检查每行数据的版本号。下面看一下,当事务隔离级设置为REPEATABLE READ时,MVCC在实际操作中的应用方式:
SELECT
InnoDB检查每行数据,确保它们符合两个标准:
-
InnDB只查找版本早于当前事务版本的数据行(也就是数据行的版本必须小于等于事务的版本),这确保了当前事务读取的行都是在事务开始前已经存在的,或者是由当前事务创建或修改的行。
-
数据行的删除版本必须是未定义的,或是大于事务版本的,这保证了事务读取的行,在事务开始是未被删除的。
只有通过上述两项测试的数据行,才会被当做查询结果返回。
INSERT
InnoDB为每个新增行记录当前系统版本号。
DELETE
InnoDB为,删除行记录当前系统版本号,作为行删除标识。
UPDATE
InnoDB会为每个需要更新的行,建立一个新的行拷贝,井且为新的行拷贝,记录当前的系统版本号。同时,也为更新前的旧行,记录系统的版本号,作为旧行的删除版本标识。
保存这些额外记录的好处,是使大多数读操作都不必申请加锁,这使读操作变得尽可能的快,因为读操作只要选取符合标准的行数据即可。这种方式的缺点是,存储引擎必须为每行数据,存储更多的额外数据,做更多的行检查工作,以及处理一些额外的整理操作(Housekeeping Operations)。
MVCC只工作在REPEATABLE READ和READ COMMITTED两个隔离级。READ UNCOMMITTED隔离级不兼容MVCC,
因为在任何情况下,该隔离级下的查询,不读取符合当前事务版本的数据行,而读取最新版本的数据行。SERIALIZABLE隔离级也不兼容MVCC,因为该级下的读操作会对每一个返回行都进行加锁。表1-2汇总了MySQL中的各种加锁模型和并发级别。
表1-2:使用默认隔离级的MySQL锁定模型和并发性
加锁策略 | 并发 | 系统开销 | 引擎 |
---|---|---|---|
表级加锁 | 最低 | 最低 | MyISAM,Merge,Memory |
行级加锁 | 高 | 高 | NDB Cluster |
支持MVCC的行级加锁 | 最高 | 最高 | InnoDB、Falcon、PBXT、solidDB |