MVCC 多版本控制: 指的是一种提高并发的技术. 最早的数据库系统, 只有读读之间可以并发, 读写, 写读, 写写都要阻塞. 引入多版本之后, 只有写写之间相互阻塞, 其他三种操作都可以并行, 这样大幅度提高了 InnoDB 的并发度. 在内部实现中, 与 Postgres 在数据行上实现多版本不同, InnoDB 是在 undolog 中实现的, 通过 undolog 可以找回数据的历史版本. 找回的数据历史版本可以提供给用户读(按照隔离级别的定义, 有些读请求只能看到比较老的数据版本), 也可以在回滚的时候覆盖数据页上的数据. 在 InnoDB 内部中, 会记录一个全局的活跃读写事务数组, 其主要用来判断事务的可见性.
MySQL 的大多数事务型存储引擎实现的都不是简单的行级锁. 基于提升并发性能的考虑, 它们一般都同时实现了多版本并发控制(MVCC). 不仅仅是 MySQL, 包括 Oracle,PostgreSQL 等其他数据库系统也都实现了 MVCC, 但是各自的实现机制并不相同, 因为 MVCC 并没有一个统一的标准. MVCC 在很多情况下避免了加锁操作, 因此开销更低. 大多数的 MVCC 都实现了非阻塞的读操作, 写操作也只锁定必要的行.
MVCC 的实现, 是通过保存数据在某个时间点的快照来实现的. 也就是说, 不管需要执行多长时间, 每个事务看到的数据是一致的. 根据事务开始的时间不同, 每个事物对同一张表, 同一时刻看到的数据可能是不一样的. 不同存储引擎的 MVCC 实现是不同的, 典型的有乐观 (optimistic) 并发控制和悲观 (pessimistic) 并发控制.
MVCC 只在 REPEATABLE READ 和 READ COMMITTED 两个隔离级别下工作. 其他两个隔离级别都和 MVCC 不兼容, 因为 READ UNCOMMITTED 总是读取最新的数据行, 而不是符合当前事务版本的数据行, 而 SERIALIZABLE 会对所有读取到的行都加锁.
MVCC 的优缺点:
MVCC 的目标是追求数据库处理高并发能力, 实现了非阻塞的读操作.
但保存这两个额外的系统版本号, 使大多数读操作都可以不用加锁, 这样设计使得读数据操作很简单, 性能很好, 并且也能保证只会读取到符合标准的行, 不足之处是每行记录都需要额外的存储空间, 需要做更多的行检查工作, 以及一些额外的维护工作.
来源: http://www.bubuko.com/infodetail-3090136.html