数据库事务一：ACID 中的 C 是多余的-CSDN博客

本文链接：https://blog.csdn.net/antsmall/article/details/138758417

本文打算探讨 ACID 中的 C，因为它的定位有些模糊。

学得比较杂的朋友都知道，数据库事务模型的 ACID 里有个 C，分布式的 CAP 理论里也有个 C，刚好中文又都翻译成 “一致性”，就让人很头大了。

这个在《数据密集型应用系统设计》里有详细的介绍[1]，读完后就很清晰了:

CAP理论中，一致性一词用来表示线性化。
而在ACID中，一致性主要指数据库处于应用程序所期待的 “预期状态”。

更可贵的是，这本书解答了一个困惑我很久的问题，即 ACID 里面的 C，不是数据库可以保证的事情，应该是靠应用层来保证。原文如下[1]:

ACID中的一致性主要是指对数据有特定的预期状态，任何数据更改必须满足这些状态约束（或者恒等条件）。例如，对于一个账单系统，账户的贷款余额应和借款余额保持平衡。如果某事务从一个有效的状态开始，并且事务中任何更新操作都没有违背约束，那么最后的结果依然符合有效状态。

这种一致性本质上要求应用层来维护状态一致（或者恒等），应用程序有责任正确地定义事务来保持一致性。这不是数据库可以保证的事情：即如果提供的数据修改违背了恒等条件，数据库很难检测进而阻止该操作（数据库可以完成针对某些特定类型的恒等约束检查，例如使用外键约束或唯一性约束。但通常主要靠应用程序来定义数据的有效/无效状态，数据库主要负责存储）。

原子性，隔离性和持久性是数据库自身的属性，而 ACID 中的一致性更多是应用层的属性。应用程序可能借助数据库提供的原子性和隔离性，以达到一致性，但一致性本身本不源于数据库。因此，字母C其实并不应该属于ACID【注1】。

注1：Joe Hellerstein 曾经在文献7中评论，字母C只是为了使ACID这个缩略词听起来更为顺口，当时并非觉得这是件很重要的事情。

上文中提到的 “文献7” 是这篇论文：Theo Härder and Andreas Reuter: “Principles of Transaction-Oriented Database Recovery”。

所以，挺搞笑的，“当时并非觉得这是件很重要的事情” 造成了我的烦恼。

说回这个 “C” 本身，对啊，数据库怎么会知道你的业务数据是不是一致的，它根本就不知道 A 和 B 的账户要平衡啊，也不应该知道这些细枝末节的，所以这个 C 完全是需要靠业务逻辑依赖数据库的 A I D 这三个属性去实现的。