事务

1 事务

事务就是一组原子性的SQL查询，或者说一个独立的工作单元。事务内的语句，要么全部执行成功，要么全部执行失败。

例子：银行应用是解释事务必要性的一个经典例子。假设一个银行的数据库有两张表：支票（checking）表和储蓄（savings）表。现在要从用户Jane的支票账户转移200美元到她的储蓄账户，那么需要至少三个步骤：

1.检查支票账户的余额高于200美元。

2.从支票账户余额中减去200美元。

3.在储蓄账户余额中增加200美元。

上述三个步骤的操作必需打包在一个事务中，任何一个步骤失败，则必须回滚所有的步骤。

SQL:

1.START TRANSACTION;

2.SELECT balance FROM checking WHERE customer_id = 10233276;

3.UPDATE checking SET balance = balance -200.00 WHERE customer_id = 10233276;

4.UPDATE savings SET balance = balance + 200.00 WHERE customer_id = 10233276;

5.COMMIT;

1.1 ACID

除非系统通过严格的ACID测试，否则空谈事务的概念是不够的。ACID表示原子性、一致性、隔离性和持久性。一个运行良好的事务处理系统，必需具备这些标准特征。

1.1.1 原子性

一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作，这就是事物的原子性。

1.1.2 一致性

数据库总是从一个一致性的状态转换到另外一个一致性的状态。在前面的例子中，一致性确保了，即使在执行第三、四条语句之间时系统崩溃了，支票账户中也不会损失200美元，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中。

关于一致性的理解：①一致性是指系统从一个正确的状态,迁移到另一个正确的状态.什么叫正确的状态呢?就是当前的状态满足预定的约束就叫做正确的状态。②事务开始和结束之间的中间状态不会被其他事务看到（If related data is being updated across multiple tables, queries see either all old values or all new values, not a mix of old and new values.）

1.1.3 隔离性

通常来说（后面隔离级别会用到），一个事务所做的修改在最终提交以前，对其他事务是不可见的。

1.1.4 持久性

一旦事务提交，则其所做的修改会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。但是其实不可能做到100%的持久性保证（如果数据库本身就能做到真正的持久性，那就不需要通过备份来增加持久性了）。

1.2 隔离级别

1.2.1 READ UNCOMMITTED（未提交读）

在该级别下，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这被称为“脏读”。

1.2.2 READ COMMITTED（提交读）

大多数数据库系统的默认隔离级别都是READ COMMITTED（但MySQL不是）。READ COMMITTED 满足前面提到的隔离性的简单定义：一个事务，只能“看见”已经提交的事务所做的修改。换句话说，一个事务从开始知道提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复读，因为两次执行同样的查询，可能会得到不一样的结果。

1.2.3 REPEATABLE READ（可重复读）

REPEATABLE READ 解决了脏读的问题。该级别保证了在同一个事务中多次读取同样记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行。

例子：假如，中午去食堂打饭吃，看到一个座位是空的，便屁颠屁颠的去打饭，回来后，发现这些座位都还是空的（重复读），窃喜。走到跟前刚准备坐下时，却惊现一个恐龙妹，严重影响食欲。仿佛之前看到的空座位是“幻影”一样。

1.2.4 SERIALIZABLE（可串行化）

SERIALIZABLE是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说，SERIALIZABLE会在读取的每一个数据行都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到这个隔离级别。

对于可重复读，查询只承认在事务启动前就已经提交完成的数据；对于提交读，查询只承认在语句启动前就已经提交完成的数据；

1.3 多版本并发控制

InnoDB的MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。下面看一下MVCC具体是如何操作的：

SELECT

InnoDB会根据以下两个条件检查每行记录：

a. InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。

b. 行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。

INSERT

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

DELETE

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

UPDATE

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

MVCC也引入了一个问题：如何移除已废弃的和将不会被读到的数据版本？

解决方案1：一个进程定期的扫描并删除已废弃的版本。具体操作起一个stop-the-world进程，获取当前正在进行的所有事物的版本号，取最小版本号，然后遍历整张表，将每一条数据的删除时间与这个最小版本号进行比较，如果小于该最小版本号即可删除。这个方案显而易见的缺点就是需要个定期的stop-the-world。

解决方案2：大部分数据库采用的方式，将存储结构分为两部分，即数据部分和undo log部分，数据部分始终保留数据的最后一个版本，undo log部分可以重现数据的历史版本。但是这种方法有一定的限制，在频繁的更新操作情况下，undo log部分会超出运行空间，从而导致事务无法获取它们的快照数据，进而该事物被丢弃。