最近看了一点资料，准备写一个大话题。
?
事务，是所有数据库讲义中最核心的话题。它本质上是一系列连续的，逻辑相关的数据库操作的组合。随便翻开一本书，都会告诉你，事务必须满足下面四个属性：
?
ACID（Atomic，Consistency，Isolation，Durability）
?
按照属性即实体的观点：数据库事务就是 ACID，符合 ACID 的就是数据库事务。因此我们可以得出一个公式：
?
数据库事务 = ACID
?
抛开课本上那些苦涩难懂的定义，如何理解 ACID ？?
?
首先，我们不用去读 Jim Gray 的《Transaction Processing: Concepts and Techniques》。——为什么数据库能在半个世纪内如此受欢迎，以至于取代了其他的数据存储方式？ 显然是因为它能够满足业务的需要。那么业务最需要什么？?
?
数据的可靠性。
?
用学术的语言说是数据的“完整性约束”——可靠的数据一定是符合“完整性约束”的数据。而“完整性约束”是什么？ 学术语言说“完整性约束”是建立在业务数据集上的“不变式（Invariant）”。那“不变式（Invariant）”又是什么？...?
?
呃。抛开这些学术概念，业务上的数据可靠性可以从两方面理解： 数据首先必须可靠的存储，然后必须可靠的更新。
?
记住，可靠的意义是符合数据的?完整性约束?——可以简单的看做业务规则。例如，账户金额不能为负，入出账必须平衡都是规则。
?
接下来，ACID 的含义?已经不难理解了：
?
A?- 原子化更新。业务操作要么全部完成, 要么全都不做, 不容忍中间状态。
?
C?- 事务开始前和结束后，数据的完整性（约束）不会被破坏。注意了，ACID 定义的 Consistency 跟现在大家常说的一致性（数据在分布式节点的一致）不一样，这里采用学术界的原始定义。
?
? ? 这儿再一次提到了?完整性约束。区别是，ACID 把 C 限制在一个事务单元内，强调事务必须保证数据从一个一致性状态进入另一个一致性状态，事务的结束和数据的一致性之间没有时差。
?
I?- 事务隔离是业务选择的。数据库定义了 4 种隔离级别：
?
? ??Read committed
?
? ? 业务的中间状态对外不可见。很容易找到的一个例子是：甲向乙转账，银行先向乙的账户转入 100 元，再从甲的账户扣除 100 元。在银行扣款前，甲、乙的账户里都有 100 元。如果这一中间状态对外可见——甲和乙就有机会都花掉这 100 元，让银行扣款失败，而且没有办法追回。
?
? ??Repeatable reads / Serializable
?
? ? 这两个级别都在限制事务执行时，其他事务提交的更新是否可见。但是程度不同。Repeatable reads 只限制行，而 Serializable 限制整个数据集。
?
? ? 举个简单的例子来理解：生成业务报表，过程先查询订单明细数据，再查询汇总数据。如果业务在处理完明细数据后，又读到了其他业务修改的订单金额 (这会违反 Repeatable reads)，或者又读到了新的订单 (这会违反 Serializable)，那么最终得到的汇总数据就会与明细数据不一致，这对于商业敏感的报表是无法接受的。
?
? ??Read uncommitted
?
? ? 业务的中间状态对外可见，不需要事务隔离。这样看似危险，但不一定会产生业务问题。例如，在一个真实的转账里：银行会先从甲的账户扣除 100 元，再向乙的账户转入 100 元。这样，在乙账户到账前，甲的账户已经扣掉了 100 元。显然，即使这个中间状态对外可见，甲、乙也没有任何机会造成银行转账失败。
?
D?- 业务数据不会丢失。事务结束后，除非数据被其他业务更新，否则不会变化。
?
理解 ACID
?
在 ACID 里，数据的可靠性是业务的根本需求。
?
如果不满足 A
