拒绝数据“错乱”：一文读懂数据库事务的四大特性（ACID）

原创已于 2026-04-13 00:02:02 修改 · 544 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

收录于

分布式事务

于 2019-06-08 16:39:59 首次发布

从“混乱”到“秩序”：为何需要事务？

在数字世界的底层逻辑中，数据的每一次变动都如同精密仪器中的齿轮咬合，容不得半点差错。然而，现实世界的运行环境充满了不确定性与混沌。如果没有一种强有力的机制来约束和管理这些数据的变动，我们所依赖的银行系统、电商平台乃至社交网络，都将陷入一片混乱。事务，正是为了终结这种混乱，建立秩序而诞生的核心概念。

场景引入：没有“事务”的世界

想象一下，你正在使用一款文档编辑软件撰写一份至关重要的报告。当你点击“保存”按钮时，软件开始将数据写入硬盘。就在写入进度条走到 50% 的时候，突然停电了。当你再次打开电脑，重新打开这份文档时，你看到的不是保存前的旧版本，也不是完整的新版本，而是一堆乱码 —— 前半部分是新的，后半部分却是旧的，甚至夹杂着未写入完成的空白字符。这份文档已经彻底损坏，无法阅读，更无法修复。

这就是没有“事务”保护的世界。在数据库领域，这种场景更为致命。假设一个电商网站的库存系统没有事务机制，当一位顾客下单购买一件商品时，系统需要执行两个操作：一是在订单表中创建一条新记录，二是在库存表中将该商品的数量减一。如果系统在处理完订单记录后突然崩溃，那么结果就是：顾客拥有了订单，但库存并没有减少。这会导致库存数据虚高，后续的商品管理、补货决策都将基于错误的数据进行，最终引发一系列连锁反应，导致整个供应链的混乱。

这种“半吊子”的状态，是任何可靠系统都必须避免的。我们需要一种机制，能够确保一系列相关的操作要么全部成功，要么全部失败，绝不允许出现这种破坏数据完整性的中间状态。

核心定义：最小逻辑工作单元

为了解决上述问题，数据库领域引入了“事务”的概念。从定义上讲，事务是数据库管理系统执行过程中的一个最小逻辑工作单元。这个定义包含了两层核心含义。

首先是“逻辑工作单元”。这意味着事务是由一个或多个操作组成的集合。这些操作在业务逻辑上是紧密关联、不可分割的。例如，上述的“创建订单”和“减少库存”虽然在物理上是两条不同的数据库指令，但在业务逻辑上，它们共同构成了“完成一笔交易”这个完整的事件。因此，它们必须被捆绑在一起，作为一个整体来对待。

其次是“最小”。这强调了事务的原子性，即它是不可再分的。对于数据库系统而言，它不关心事务内部包含了多少条 SQL 语句，它只将这个事务视为一个单一的、不可分割的操作。这个操作的结果只有两种可能：成功或失败。不存在“部分成功”这种状态。这种“全有或全无”的特性，是事务最根本的灵魂。

形象比喻：一份“神圣契约”

我们可以将事务比作一份与数据库签订的“神圣契约”。当你向数据库发起一个事务时，你实际上是在提交一份包含多项条款的请求。这份契约的核心条款就是：“要么全部满足，要么全部作废”。

数据库作为契约的另一方，会郑重地接受这份请求。它会小心翼翼地执行契约中的每一项条款。如果所有条款都能顺利执行，那么数据库就会正式签署这份契约（即“提交”事务），所有的更改都将成为现实，并对其他用户可见。如果在执行过程中，任何一个条款因为任何原因（如系统错误、数据冲突等）无法满足，那么整份契约将立即被视为无效（即“回滚”事务）。数据库会撤销之前所有已经执行的操作，让一切恢复到契约签订之前的状态，仿佛这份契约从未存在过一样。

这份“神圣契约”的比喻，生动地诠释了事务的本质：它通过强制性的规则，在充满不确定性的计算机系统中，为数据操作建立了一个确定性的、可靠的边界。正是这个边界，将混乱挡在了门外，为数据的准确性和一致性提供了坚实的保障。

核心概念：ACID 四大特性详解

如果说我们确立了事务是“神圣契约”，那么 ACID 就是这份契约中必须严格遵守的四条“黄金法则”。这四个字母分别代表了原子性、一致性、隔离性和持久性。它们共同构成了一个坚固的防御体系，确保数据在任何极端情况下都能保持完整与可靠。

原子性（Atomicity）：不可分割的“整体”

原子性，顾名思义，是指事务是一个不可分割的最小工作单位。就像物理学中的原子在化学反应中不可再分一样，事务中的所有操作要么全部成功，要么全部失败回滚，不存在执行了一半的中间状态。

在这里插入图片描述

在原子性的视角下，事务内部的步骤不再是独立的个体，而是一个紧密相连的整体。例如，在一个涉及资金划转的事务中，包含“A 账户扣款”和“B 账户加款”两个步骤。如果系统在执行完第一步后突然崩溃，原子性机制会立即介入，撤销已经执行的扣款操作，就像什么都没发生过一样。这就像是跳水比赛，如果动作做到一半失败了，那么整个动作就会被判定为零分，而不是给一半的分数。

原子性主要应对的是系统故障，如断电、宕机或运行错误。它确保了在故障发生时，数据库不会残留任何“半成品”数据。在数据库理论中，这通常通过“撤销日志”机制来保障：系统在执行操作前会先记录一条“反向操作”的日志，一旦事务失败，系统读取日志执行反向操作，从而完美复原。

一致性（Consistency）：严守规则的“合法”

一致性是事务追求的最终目标，它要求事务执行前后，数据库必须始终处于“合法状态”。这里的“合法”，是指数据必须满足所有的完整性约束。

在这里插入图片描述

很多初学者容易将一致性误解为“业务逻辑上的守恒”（如转账前后总金额不变）。虽然这也是对的，但在数据库通用理论中，一致性的内涵更为广泛和基础。它指的是数据必须符合预设的规则，包括但不限于：

实体完整性：例如，主键必须唯一且不能为空。你不能插入两条 ID 完全相同的用户记录。
参照完整性：例如，外键约束。你不能在订单表中插入一条指向“不存在的用户”的订单记录。
域完整性：例如，数据类型和范围限制。年龄字段不能是负数，性别字段只能是“男”或“女”。

如果一个事务试图破坏这些规则，比如试图将一个字符串插入到整数类型的字段中，或者试图删除一个被其他数据引用的记录，数据库系统会判定该事务破坏了一致性，从而拒绝执行并报错。一致性确保了数据不仅没有丢失，而且是“有意义”且“符合规范”的。

隔离性（Isolation）：并发环境下的“独立”

在现实世界中，数据库往往同时服务于成千上万个用户。隔离性就是为了处理这种“多任务并发”场景而存在的。它规定：当多个事务并发执行时，一个事务的执行不应被其他事务干扰。每个事务都应该感觉不到有其他事务在同时执行，就像世界上只有它自己在独享数据库一样。

在这里插入图片描述
然而，完全的隔离往往意味着性能的下降，因此在数据库理论中，定义了不同程度的隔离级别，以平衡数据的安全性与系统的并发性能。

并发异常：脏读、不可重复读、幻读

要理解隔离级别，我们首先需要认识三种因隔离不当而产生的数据异常现象。

脏读
事务 A 读取了事务 B 已经修改但尚未提交的数据。如果 B 随后回滚了，A 读到的就是“脏数据”（无效数据）。
不可重复读
事务 A 在同一个事务内，两次读取同一行数据，结果不一样。这是因为中间有事务 B 修改并提交了这行数据。

脏读和不可重复读有什么区别？
脏读：读到的数据是另一个事务未提交的数据。
不可重复读：读到的数据是另一个事务已提交的数据。
幻读
事务 A 在同一个事务内，两次查询同一范围的数据，结果集数量不一致。这是因为中间有事务 B 插入或删除了符合该范围的新数据。

幻读和不可重复读有什么区别？
相同点：幻读和不可重复读都是读到了另一个事务已提交的数据（脏读是未提交）。
不同点：不可重复读是读到的都是同一个数据值（同一条数据）；幻读是针对一批整体的数据（数据总数或一张表）。

隔离级别：SQL 标准的四个层级

为了解决上述问题，SQL 标准定义了四种隔离级别，由低到高依次为：

读未提交（Read Uncommitted）
这是最低的级别。事务可以读取未提交的数据。这种级别下，脏读、不可重复读和幻读都可能发生。

如无特殊情况，基本是不会使用这种隔离级别的。
读已提交（Read Committed）
事务只能读取已经提交的数据。这解决了脏读问题，但不可重复读和幻读仍可能发生。

这就要说到另一个机制“快照（snapshot）”，而这种既能保证一致性又不加锁的读也被称为“快照读（Snapshot Read）”。假设没有“快照读”，那么当一个更新的事务没有提交时，另一个对更新数据进行查询的事务会因为无法查询而被阻塞，这种情况下，并发能力就相当的差。而“快照读”就可以完成高并发的查询，不过，“读提交”只能避免“脏读”，并不能避免“不可重复读”和“幻读”。
可重复读（Repeated Read）
保证在同一个事务内，多次读取同一数据的结果是一致的。这解决了脏读和不可重复读问题，但在标准定义中，幻读仍可能发生。

它也是 MySql 的默认隔离级别。

在这个级别下，普通的查询同样是使用的“快照读”，但是，和“读提交”不同的是，当事务启动时，就不允许进行“修改操作（Update）”了，而“不可重复读”恰恰是因为两次读取之间进行了数据的修改，因此，“可重复读”能够有效的避免“不可重复读”，但却避免不了“幻读”，因为幻读是由于“插入或者删除操作（Insert or Delete）”而产生的。
可串行化（Serializable）
这是最高的隔离级别。它强制事务串行执行，就像排队一样，一个接一个地处理。这彻底解决了所有并发问题，但代价是系统性能大幅下降，并发能力极低。

根据以上描述，可整理出如下在不同隔离级别下能出现的现象关系表格：

隔离级别	脏读	不可重复读	幻读
读未提交（Read Uncommitted）	✔	✔	✔
读已提交（Read Committed）	✖	✔	✔
可重复读（Repeated Read）	✖	✖	✔
可串行化（Serializable）	✖	✖	✖

持久性（Durability）：永久生效的“确定”

持久性是事务的最后一道防线。它承诺：一旦事务提交，它对数据库中数据的改变就是永久性的。即使接下来数据库发生了故障（如断电、系统崩溃），提交过的数据也不会丢失。

在这里插入图片描述

持久性关注的是数据的“未来”。原子性保证了事务执行过程中的“生与死”，而持久性则保证了事务成功后的“永恒”。

在理论层面，持久性通常通过“重做日志”机制来实现。当事务提交时，数据库不仅仅是将数据写入磁盘的数据文件（这通常很慢），而是先将“发生了什么操作”记录到日志文件中。日志文件的写入速度非常快，而且是顺序写入。只要日志记录成功，即使数据文件还没来得及完全更新系统就断电了，当数据库重启时，它也可以通过读取日志，重新执行那些操作，从而恢复数据。这就是持久性的核心逻辑：只要留下了“痕迹”，数据就拥有了重生的能力。

总结回顾：构建可靠系统的基石

当我们完整走过 ACID 的四大特性，就像完成了一次对数据可靠性大厦的勘探。从地基（原子性）到框架（一致性），从内部隔断（隔离性）再到外部防护（持久性），这四个特性并非孤立存在，而是相互咬合、互为支撑，共同构建了一个能够抵御各种风险的坚固系统。

核心回顾：ACID如何保障数据完整性？

回顾 ACID 的四大特性，我们可以将它们理解为一个层层递进的防御体系，每一层都针对数据完整性可能面临的特定威胁。

原子性是第一道防线，它应对的是“失败”。无论是系统崩溃、断电还是程序错误，原子性确保了事务这个工作单元不会出现“半途而废”的尴尬境地。它像一个拥有“时光倒流”能力的守护者，一旦操作失败，就立刻将所有步骤撤销，让数据回到事务开始前的纯净状态。

一致性是最终的目标，它应对的是“无效”。它确保数据不仅要被完整地写入，更要“正确地”写入。它像一位严苛的法官，依据预设的所有规则（主键、外键、唯一性约束等）来审判每一次数据变更。任何试图破坏规则的操作都会被拒之门外，从而保证了数据库从一个合法状态平滑地过渡到另一个合法状态。

隔离性是并发世界的秩序，它应对的是“干扰”。在多用户同时访问的复杂环境中，隔离性为每个事务划定了一个独立的“结界”。它通过不同的隔离级别，灵活地控制着事务间的可见性，有效防止了脏读、不可重复读等并发异常，确保了每个事务都能在不受打扰的情况下，基于一个稳定、一致的数据视图进行操作。

持久性是面向未来的承诺，它应对的是“遗忘”。一旦事务成功提交，持久性就保证了其结果被永久铭刻在数据库中。它像一位不知疲倦的记录员，将每一次成功的变更都写入永不磨灭的史册（重做日志），确保即使在最极端的灾难发生后，数据依然能够被完整地恢复，承诺永不落空。

理论定位：关系型数据库的强一致性基石

ACID 不仅仅是一组技术特性的集合，它更是关系型数据库（RDBMS）设计哲学的核心体现。它所代表的“强一致性”模型，是关系型数据库区别于其他类型数据库（如NoSQL）最根本的标志。

在关系型数据库的世界里，数据的准确性和可靠性被置于至高无上的地位。ACID原则正是这种价值观的集中体现。它要求数据库系统不惜牺牲一部分性能和灵活性，也要换取数据的绝对正确。这种设计哲学使得关系型数据库在金融、财务、订单管理等对数据一致性要求极高的核心业务场景中，始终占据着不可动摇的统治地位。

因此，理解 ACID，就是理解关系型数据库的灵魂。它是我们构建一切上层应用的理论基石。当我们谈论数据库事务时，我们谈论的本质上就是 ACID。它为后续更复杂、更前沿的理论（如分布式事务中的CAP定理和BASE理论）提供了参照的基准。可以说，ACID 是每一位数据从业者和开发者必须掌握的第一课，也是最重要的一课。