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 里，数据的可靠性是业务的根本需求。

 

如果不满足 A，则业务的一组操作并没有全部完成。比如写入了订单，但是没有写入订单明细，一定会违反业务的数据完整性。

 

而不满足 D，则数据是易变的。昨天写的订单今天也许就找不到了，业务的数据可靠性得不到保证。

 

C 保护数据在事务前后的完整性。这不是必须的，有些业务可以允许时差。继续用上面的转账作为例子：甲向乙转入 100 元，银行先从甲的账户扣除 100 元，承诺明天到账。甲信任银行，认为这是合理的。第二天，银行向乙的账户转入 100 元，结束这笔业务。

 

用户（甲）可以容忍账务临时的不一致。因此，从这个意义来看 C 是场景相关的。

 

最后，I 根据业务场景的需要定义了 4 个隔离级别。有些业务场景需要强 Serializable 的事务隔离，有些场景完全不需要事务隔离。很明显，I 也是场景相关的。