mysql原理和优化使用 > mysql事务
MVCC(多版本并发控制)

简介

MVCC(Multi-Version Concurrency Control)即多版本并发控制。
MySQL的大多数事务型(如InnoDB,Falcon等)存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑,他们一般都同时实现了MVCC。当前不仅仅是MySQL,其它数据库系统(如Oracle,PostgreSQL)也都实现了MVCC。值得注意的是MVCC并没有一个统一的实现标准,所以不同的数据库,不同的存储引擎的实现都不尽相同。

MVCC的实现原理

undo log

为了便于理解MVCC的实现原理,这里简单介绍一下undo log的工作过程

在不考虑redo log 的情况下利用undo log工作的简化过程为:

序号动作
1开始事务
2记录数据行数据快照到undo log
3更新数据
4将undo log写到磁盘
5将数据写到磁盘
6提交事务

1)为了保证数据的持久性数据要在事务提交之前持久化
2)undo log的持久化必须在在数据持久化之前,这样才能保证系统崩溃时,可以用undo log来回滚事务

Innodb中的隐藏列

Innodb通过undo log保存了已更改行的旧版本的信息的快照。
InnoDB的内部实现中为每一行数据增加了三个隐藏列用于实现MVCC。

列名长度(字节)作用
DB_TRX_ID6插入或更新行的最后一个事务的事务标识符。(删除视为更新,将其标记为已删除)
DB_ROLL_PTR7写入回滚段的撤消日志记录(若行已更新,则撤消日志记录包含在更新行之前重建行内容所需的信息)
DB_ROW_ID6行标识(隐藏单调自增id)

结构

数据列..DB_ROW_IDDB_TRX_IDDB_ROLL_PTR

MVCC工作过程

MVCC只在READ COMMITED 和 REPEATABLE READ 两个隔离级别下工作。READ UNCOMMITTED总是读取最新的数据行,而不是符合当前事务版本的数据行。而SERIALIZABLE 则会对所有读取的行都加锁

SELECT

InnoDB 会根据两个条件来检查每行记录:

  • InnoDB只查找版本(DB_TRX_ID)早于当前事务版本的数据行(行的系统版本号<=事务的系统版本号,这样可以确保数据行要么是在开始之前已经存在了,要么是事务自身插入或修改过的)

  • 行的删除版本号(DB_ROLL_PTR)要么未定义(未更新过),要么大于当前事务版本号(在当前事务开始之后更新的)。这样可以确保事务读取到的行,在事务开始之前未被删除。

INSERT

InnoDB为新插入的每一行保存当前系统版本号作为行版本号

DELETE

InnoDB为删除的每一行保存当前的系统版本号作为行删除标识

UPDATE

InnoDB为插入一行新记录,保存当前系统版本号作为行版本号,同时保存当前系统版本号到原来的行作为行删除标识

使用MVCC优势以及一致性读

    通过使用MVCC(Multi-Version Concurrency Control)算法自动提供并发控制。MVCC维持一个数据的多个版本使读写操作没有冲突。也就是说数据元素X上的每一个写操作产生X的一个新版本,GBase 8m为X的每一个读操作选择一个版本。由于消除了数据库中数据元素读和写操作的冲突,GBase 8m得到优化,具有更好的性能。特别是对于数据库读和写两种方法,他们不用等待其他同时进行的相同数据写和读的完成。在并发事务中,数据库写只等待正在对同一行数据进行更新的写,这是现有的行级锁的弱点。同时MVCC回收不需要的和长时间不用的内存,防止内存空间的浪费。MVCC优化了数据库并发系统,使系统在有大量并发用户时得到最高的性能,并且可以不用关闭服务器就直接进行热备份。

    在 GBase 中的查询功能通过 MVCC 提供的一致性非锁读(在下文我们简称为一致性读),就是提供通过数据库在一个时间点上的快照来实现信息的查询。查询只是对那些在这个时间点之前提交的事务所做的变更,而并不关注在时间点之后的变更或未提交的事务。当然,若是该事务自身进行的变更,对于查询是可见的。

GBase 的默认级别是 READ COMMITTED ,在该隔离级别下事务中的查询语句,使用当前时间戳进行一致性读,每次查询的时间戳是不相同的。

但对 REPEATABLE READ 隔离级别,在同一个事务中的所有一致性读,使用的时间戳均是第一个查询的时间戳,这样读取的也就是由该事务第一次读建立起来的数据快照。用户只有通过提交当前事务,并发出一个新的查询才会得到新的数据快照。

    一致性读是 GBase 在 READ COMMITTED 和 REPEATABLE READ 隔离级别下,处理 SELECT 语句中使用的默认模式。一致性读在它读的数据上不设置任何锁,因此在一致性读某个表的同时,其它用户均可以修改这个表。

注意在 DROP TABLE 和 ALTER TABLE 运作时,一致性读无效 。一致性读在 DROP TABLE 上无效是因为 GBase 不能使用已经 drop 的表,该表已经删除。一致性读在 ALTER TABLE 上无效是因为 GBase 会在事务内,重新创建一个新表并从旧表向新表插入记录。这样当用户再次执行一致性读时,在新表中将看不到任何行,因为在新表中的数据都在第一次一致性读的快照之外。


mysql官网文档

https://dev.mysql.com/doc/refman/5.7/en/innodb-multi-versioning.html