MVCC (多版本并发控制)与数据库事务

我是小懒猴，人狠话不多，直接上才艺。

总结：

1.数据库事务是针对于单机，ACID ，单个线程之间的相互事务
2.MVCC主要处理多线程-多版本并发控制,各个线程之间的事务处理，只支持读已提交，可重复读两个事务，每行数据有行ID，事务ID，回滚指针

MVCC 能解决什么问题

1.在并发读数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写性能。
2.可以解决脏读、不可重复读、幻读等事务隔离问题（不能解决更新丢失的问题）。

所以说 MVCC 就是开发人员不满意只让数据库采用悲观锁（加锁）这样性能不佳的形式去解决读-写的问题而提出的解决方案，所以在数据库中，因为有了 MVCC ，所以我们可以形成两个组合：

1.MVCC + 悲观锁
		MVCC解决读写冲突，悲观锁解决写-写冲突
2.MVCC + 乐观锁
		MVCC解决读写冲突，乐观锁解决写-写冲突。

MVCC 的实现方式有多种，典型的有乐观（optimistic）并发控制和悲观（pessimistic）并发控制。
MVCC 只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作，其他两个隔离级别都和 MVCC 不兼容，因为 READ UNCOMMITTED 总是读取最新的数据行，而不是符合当前事务版本的数据行，而 SERIALIZABLE 则会对所有读取的行都加锁。

“读已提交”（Read Committed）是一个隔离级别，而MVCC（多版本并发控制）是一种技术实现，用于在数据库系统中处理并发事务。这两者不是相互冲突的概念，而是可以协同工作的。
读已提交（Read Committed）
“读已提交” 是 SQL 标准定义的四个事务隔离级别之一。当使用 “读已提交” 隔离级别时，一个事务中的查询只能看到已经提交的事务所做的修改。也就是说，在当前事务执行过程中，其他事务提交的更新将会被看到。
这个隔离级别避免了脏读（即读取未提交事务的数据），但仍然允许非重复读和幻读的发生。非重复读是指在同一事务中，两次执行相同的查询可能会返回不同的结果集，因为其他已提交的事务更改了数据。幻读是指在同一事务中执行两次查询，第二次查询可能会看到自第一次查询以来新插入的数据行。

MVCC（多版本并发控制）

MVCC 是一种通过保留数据操作前的旧版本来支持在数据库系统中实现高并发的技术。它使得读操作可以访问数据的一个快照版本，从而不必等待正在进行的写操作完成，反之亦然。在 MVCC 模型中，每次数据更新都会生成一个新版本的数据记录，而不是直接覆盖现有记录。同时，老版本的记录会被保留下来，直到不再需要为止，以便为不同时间开始的事务提供服务。
MVCC与读已提交的结合
在支持 MVCC 的数据库系统中，如 PostgreSQL 或 MySQL 的 InnoDB 存储引擎，“读已提交” 可以通过下面的方式实现：

• 当事务 A 更新一条记录时，它会创建这条记录的新版本。
• 如果事务 B 正在运行，并且使用 “读已提交” 隔离级别，则它不会看到事务 A 对这条记录所做的更新，直到事务 A 提交。
• 一旦事务 A 提交，事务 B 在其后续的查询中将会看到事务 A 所做的更改，因为这些更改此时已经处于 “已提交” 状态。
  因此，“读已提交” 隔离级别在 MVCC 的控制下工作得很好，并且两者共同提高了数据库在并发环境中的性能。MVCC 实际上提供了一种机制来实现包括 “读已提交” 在内的多种隔离级别，而这些隔离级别又定义了不同的可见性规则。在 MVCC 中，这些规则通过判断哪些版本的数据对某个特定事务可见来实施。