一、事务 概念
事务指的是满足 ACID 特性的一组操作，可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。
ACID
- 原子性（Atomicity）
事务被视为不可分割的小单元，事务的所有操作要么全部提交成功，要么全部失败回滚。
回滚可以用回滚日志来实现，回滚日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。 - 一致性（Consistency）
数据库在事务执行前后都保持一致性状态。在一致性状态下，所有事务对一个数据的读取结果都是相同的。 - 隔离性（Isolation）
一个事务所做的修改在终提交以前，对其它事务是不可见的。 - 持久性（Durability）
一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。
使用重做日志来保证持久性。
事务的 ACID 特性概念简单，但不是很好理解，主要是因为这几个特性不是一种平级关系：
只有满足一致性，事务的执行结果才是正确的。 在无并发的情况下，事务串行执行，隔离性一定能够满足。此时只要能满足原子性，就一定能满足一致性。 在并发的情况下，多个事务并行执行，事务不仅要满足原子性，还需要满足隔离性，才能满足一致性。 事务满足持久化是为了能应对数据库崩溃的情况。
二、并发一致性问题
在并发环境下，事务的隔离性很难保证，因此会出现很多并发一致性问题。 丢失修改
T1 和 T2 两个事务都对一个数据进行修改，T1 先修改，T2 随后修改，T2 的修改覆盖了 T1 的修改。
读脏数据
T1 修改一个数据，T2 随后读取这个数据。如果 T1 撤销了这次修改，那么 T2 读取的数据是脏数据。
不可重复读
T2 读取一个数据，T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。
幻影读
T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次 读取的结果不同。
产生并发不一致性问题主要原因是破坏了事务的隔离性，解决方法是通过并发控制来保证隔离性。并发控制可以通过 封锁来实现，但是封锁操作需要用户自己控制，相当复杂。数据库管理系统提供了事务的隔离级别，让用户以一种更 轻松的方式处理并发一致性问题。
五、多版本并发控制
多版本并发控制（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种 具体方式，用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取新的数据行，无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。 版本号
系统版本号：是一个递增的数字，每开始一个新的事务，系统版本号就会自动递增。 事务版本号：事务开始时的系统版本号。 隐藏的列
MVCC 在每行记录后面都保存着两个隐藏的列，用来存储两个版本号：
创建版本号：指示创建一个数据行的快照时的系统版本号； 删除版本号：如果该快照的删除版本号大于当前事务版本号表示该快照有效，否则表示该快照已经被删除了。 Undo 日志
MVCC 使用到的快照存储在 Undo 日志中，该日志通过回滚指针把一个数据行（Record）的所有快照连接起来。
实现过程
以下实现过程针对可重复读隔离级别。
当开始一个事务时，该事务的版本号肯定大于当前所有数据行快照的创建版本号，理解这一点很关键。数据行快照的 创建版本号是创建数据行快照时的系统版本号，系统版本号随着创建事务而递增，因此新创建一个事务时，这个事务 的系统版本号比之前的系统版本号都大，也就是比所有数据行快照的创建版本号都大。
- SELECT
多个事务必须读取到同一个数据行的快照，并且这个快照是距离现在近的一个有效快照。但是也有例外，如果有一 个事务正在修改该数据行，那么它可以读取事务本身所做的修改，而不用和其它事务的读取结果一致。
把没有对一个数据行做修改的事务称为 T，T 所要读取的数据行快照的创建版本号必须小于 T 的版本号，因为如果大 于或者等于 T 的版本号，那么表示该数据行快照是其它事务的新修改，因此不能去读取它。除此之外，T 所要读取 的数据行快照的删除版本号必须大于 T 的版本号，因为如果小于等于 T 的版本号，那么表示该数据行快照是已经被删 除的，不应该去读取它。 - INSERT
将当前系统版本号作为数据行快照的创建版本号。 - DELETE
将当前系统版本号作为数据行快照的删除版本号。 - UPDATE
将当前系统版本号作为更新前的数据行快照的删除版本号，并将当前系统版本号作为更新后的数据行快照的创建版本 号。可以理解为先执行 DELETE 后执行 INSERT。
848
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
