面试必问：ACID 你真的懂了吗？

小盒子的技术分享
777 阅读14分钟

ACID 是什么？

事务处理中的 ACID 是确保数据库操作可靠性和完整性的四个核心特性

属性说明示例
原子性（Atomicity）事务是不可分割的最小操作单元，事务中的所有操作要么全部成功完成，要么全部失败回滚。用户在线购买书籍时的支付流程：
①支付扣款 ②库存扣减 ③快递下单三个步骤必须全部成功——任一步骤失败时（如库存不足），系统自动取消已付金额，退回到购物未进行状态。
一致性（Consistency）事务必须保证数据库从一个一致性状态转变到另一个一致性状态。一致性是指数据必须符合预定义的规则和约束，例如完整性约束、业务规则等。银行转账场景：
账户A向账户B转200元后，两人账户总额保持不变（若A+B原为1000元，操作完成后仍为1000）。即便系统中途崩溃，恢复后也不会出现A扣200元但B未入账的金额"凭空消失"。
隔离性（Isolation）多个事务并发执行时，每个事务都应该感觉不到其他事务的存在，就像在隔离的环境中执行一样。事务之间互相隔离，不会互相影响。航班订座系统：
当乘客A和B同时选择最后一个座位，先完成支付者的订单立即锁定座位，另一用户将实时看到"无余票"提示——避免出现系统误判导致超售。
持久性（Durability）一旦事务提交成功，对数据库的修改就应该是永久性的，即使系统发生崩溃或重启等意外情况，数据也不会丢失。线上预约挂号确认：
用户成功提交预约后，即便医院服务器遭遇断电，重启后系统依然保留该条预约记录并发送确认短信，不会因突发意外丢失数据。

MySQL 是如何保证 ACID 的？

MySQL 实现 ACID 特性主要依赖 日志系统（undo log 和 redo log）、锁机制 和 MVCC 多版本并发控制。下面是具体实现原理的详细分析：

一、Atomicity（原子性）

事务是不可分割的最小执行单位。原子性确保事务中的所有操作要么全部成功完成，要么全部失败回滚。不允许中间状态。MySQL 通过 Undo Log + 事务回滚 实现原子性：

当事务开始时，InnoDB 会记录事务修改前的数据（旧版本）到 Undo Log 中，用于事务回滚时恢复原始状态。

Undo Log 记录结构包含：原始数据值、事务ID（trx_id）、回滚指针（roll_pointer）。

Undo Log 记录的是逻辑操作，例如 "删除第 10 行"，"将字段 'name' 从 'old' 更新为 'new'" 等。

举个简单例子：

-- 事务未提交时，其他事务通过Undo Log读取原始数据（MVCC）
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- 此时Undo Log会记录balance的旧值（如200）
ROLLBACK; -- 使用Undo Log恢复数据

如果事务执行过程中发生错误或者用户显式执行 ROLLBACK，InnoDB 可以根据 Undo Log 中的记录将数据恢复到事务开始之前的状态，从而实现事务的回滚

二、Isolation（隔离性）

隔离性 (Isolation) 是 ACID 特性中的关键一环，它确保在多个事务并发执行时，每个事务都仿佛独立运行，互不干扰。 换句话说，一个事务的中间状态和操作不应该被其他并发事务感知到，从而避免数据混乱和不一致。 为了实现这种隔离效果，MySQL 的 InnoDB 存储引擎主要依赖于两大核心机制：锁机制 (Locking) 和 多版本并发控制 (MVCC)

1. 锁机制

首先，锁机制是最基础的隔离手段。InnoDB 实现了多种锁类型，以适应不同的并发场景和隔离需求。 其中，行级锁 是 InnoDB 并发控制的核心，它允许事务仅锁定需要修改的数据行，最大程度地提高了并发度。 行级锁又细分为 共享锁 (S 锁) 和 排他锁 (X 锁)，前者允许多个事务同时读取同一行数据，而后者则保证在更新或删除数据时，只有一个事务可以独占该行。

除了行级锁，MySQL 还提供 表级锁，它会锁定整个表，虽然并发度较低，但在某些特定场景（如执行 LOCK TABLES 语句）下仍然适用。

为了更高效地管理锁，InnoDB 引入了 意向锁 (Intention Locks)，它在表级别上预先声明事务对行级锁的意图，从而优化锁的检查和兼容性。

此外，在 REPEATABLE READ 和 SERIALIZABLE 这两个较高的隔离级别下，为了解决幻读问题，InnoDB 还使用了 间隙锁 (Gap Locking)，它不仅锁定已存在的记录，还锁定索引记录之间的间隙，防止其他事务在该间隙中插入新记录，从而彻底避免幻读。

我们通过一个具体的例子来说明 InnoDB 的 间隙锁（Gap Locking） 如何解决幻读问题：

假设有一张表 students，存储学生信息，主键为 id，当前数据如下：

idname
1Alice
3Bob
5Charlie

现在有两个事务 事务A 和 事务A，操作顺序如下：

  1. 事务A 执行范围查询并加锁：

    BEGIN;
SELECT * FROM students WHERE id BETWEEN 1 AND 5 FOR UPDATE;
-- 查询结果：id=1, 3, 5

    InnoDB 会为 id 索引加上 Next-Key Lock（行锁 + 间隙锁），锁定的范围包括：

    • (-∞, 1]
    • (1, 3]
    • (3, 5]
    • (5, +∞)
      （注：假设表中无其他数据）

  2. 事务B 尝试插入新数据：

    BEGIN;
INSERT INTO students (id, name) VALUES (2, 'David');  -- 尝试插入到间隙 (1,3)
-- 或者
INSERT INTO students (id, name) VALUES (4, 'Eve');    -- 尝试插入到间隙 (3,5)

    由于 事务A 的间隙锁锁定了 (1,3) 和 (3,5) 的间隙，事务B 的插入操作会被阻塞，直到 事务A 提交或回滚。

  3. 事务A 提交：

    COMMIT;

    事务B 的插入操作才会继续执行。

结果对比

  • 没有间隙锁：
    若事务A未加间隙锁（例如使用 READ COMMITTED 隔离级别），事务B可以插入 id=2 或 id=4。当事务A再次执行 SELECT 时，会看到新插入的行（id=2 或 4），导致幻读。

  • 有间隙锁：
    事务B的插入操作被阻塞，直到事务A释放锁。事务A在事务执行期间始终看到相同的数据（id=1,3,5），避免幻读。

关键点

  1. 间隙锁的锁定范围：
    InnoDB 的间隙锁不仅锁定已存在的行，还会锁定索引记录之间的“间隙”（例如 (1,3) 和 (3,5)），阻止其他事务在间隙中插入新数据。

  2. Next-Key Lock 的作用：
    Next-Key Lock = 行锁（锁定已存在记录） + 间隙锁（锁定间隙）。例如，对 id=3 的行锁会锁定范围 (1,3]。

  3. 隔离级别的影响：
    间隙锁仅在 REPEATABLE READ 隔离级别下生效。在 READ COMMITTED 级别下，InnoDB 会禁用间隙锁，幻读仍可能发生。

在实际场景中，比如在电商系统中，若一个事务正在统计某商品（例如库存范围在 100~200）的订单数量，间隙锁可以防止其他事务插入新的订单记录（例如库存为 150 的商品），确保统计结果的一致性。

2. MVCC

为了进一步提升并发性能，尤其是在读多写少的场景下，InnoDB 引入了 多版本并发控制 (MVCC)。 MVCC 的核心思想是允许事务在读取数据时，访问数据在某个时间点的快照版本，而不是直接读取最新的数据。 这样，读操作就不需要等待写操作完成，从而实现读写并发执行，显著提高了系统吞吐量。 MVCC 的实现依赖于 Undo Log 和 Read View (快照读)。 Undo Log 用于记录数据的历史版本，而 Read View 则定义了事务在读取数据时应该看到哪个版本的数据。MVCC 主要应用于 READ COMMITTED 和 REPEATABLE READ 这两个隔离级别，在这两个级别下，MVCC 可以有效减少锁的竞争，提升并发性能。

总结来说：MVCC 就是基于隐藏字段、undo_log 链和 ReadView 来实现的

3. 隔离级别与策略对比

最后，为了满足不同应用场景对隔离程度和性能的不同需求，MySQL 提供了 四种事务隔离级别。 从最低的 READ UNCOMMITTED (读未提交) 到最高的 SERIALIZABLE (串行化)，隔离级别依次增强，但并发性能也随之降低。

  • READ UNCOMMITTED 允许脏读，隔离性最弱，但性能最高；
  • READ COMMITTED 避免了脏读，但可能出现不可重复读；
  • REPEATABLE READ (InnoDB 默认级别) 在 READ COMMITTED 的基础上解决了不可重复读，但仍可能存在幻读（在某些情况下，InnoDB 通过 Next-Key Locking 尝试解决幻读）；
  • SERIALIZABLE 通过强制事务串行执行，彻底避免了所有并发问题，但并发性能也最低。
隔离级别脏读不可重复读幻读实现方式
READ UNCOMMITTED✔️✔️✔️无锁
READ COMMITTED✖️✔️✔️每个SELECT生成新Read View
REPEATABLE READ*✖️✖️✖️△首SELECT生成Read View + 间隙锁
SERIALIZABLE✖️✖️✖️所有SELECT隐式转成SELECT ... FOR UPDATE

△：MySQL通过Next-Key Lock（行锁+间隙锁组合）在REPEATABLE READ级别实际消除幻读。

三、Durability（持久性）

持久性 (Durability) 是 ACID 特性中保障数据安全性的最后一道防线。 它确保一旦事务成功提交，对数据库所做的所有更改都必须被永久地保存下来，即使系统随后发生崩溃、断电或任何其他类型的故障，已提交的数据也绝不会丢失。 为了实现这种强大的数据保障，MySQL 的 InnoDB 存储引擎采用了一系列精密的机制，其中最核心的是 Redo Log (重做日志)，并辅以 Write-Ahead Logging (WAL) 策略、 Doublewrite Buffer (双写缓冲区) 和灵活的 刷盘 (Flush to Disk) 机制，同时，Binlog (二进制日志) 也从更广泛的层面为数据持久性提供了支持。

首先，Redo Log 是 InnoDB 实现持久性的基石。 当一个事务执行过程中，InnoDB 并不会立即将数据页的修改直接写入磁盘上的数据文件，而是先将这些修改操作，例如插入、更新或删除的具体内容，以一种紧凑、高效的形式，顺序地记录到 Redo Log Buffer 中。 这里的 Redo Log 记录的是物理层面的修改，例如“将数据页 X 的偏移量 Y 处的 Z 个字节修改为新的值”。 为了保证效率，Redo Log Buffer 存在于内存中，但为了确保持久性，InnoDB 会定期或者在事务提交时，将 Redo Log Buffer 中的内容刷新到 Redo Log 文件 这一磁盘上的持久化存储。

为了进一步确保数据在极端情况下的安全性，InnoDB 遵循 Write-Ahead Logging (WAL) 预写式日志 策略。 这意味着，在任何数据页的实际修改被写入磁盘数据文件之前，必须先将相应的 Redo Log 记录落盘到 Redo Log 文件中。 这种 “先写日志，后写数据” 的机制至关重要，它保证了即使在数据页尚未完全刷入磁盘时系统发生崩溃，已经提交的事务的所有修改操作也已经安全地记录在 Redo Log 中，从而为后续的数据恢复提供了保障。

Doublewrite Buffer (双写缓冲区) 是 InnoDB 为了应对数据页“部分写失效 (Partial Write)” 问题而引入的增强机制。 在数据页从内存刷新到磁盘数据文件的过程中，可能会因为断电等意外情况，导致数据页只写入了一部分，造成数据损坏。 为了避免这种情况，InnoDB 在数据页最终写入数据文件之前，会先将其完整地写入 Doublewrite Buffer 区域。 Doublewrite Buffer 是磁盘上一个连续的存储区域，InnoDB 会先顺序写入，保证写入的原子性。 之后，再将数据页从 Doublewrite Buffer 拷贝到真正的数据文件位置。 这样，即使在数据页写入过程中发生崩溃，InnoDB 在重启恢复时，可以通过 Doublewrite Buffer 检查数据页的完整性。 如果发现数据页写入不完整或已损坏，可以从 Doublewrite Buffer 中找到该数据页的完整副本进行恢复，从而有效地避免了数据页部分写入导致的数据丢失。

Flush to Disk 机制 则提供了对 Redo Log 和数据页刷盘行为的精细控制。 MySQL 提供了多个参数，例如 innodb_flush_log_at_trx_commit 参数控制 Redo Log 何时刷盘，可以设置为每次事务提交都刷盘 (最安全，但性能较低)，或者定期刷盘 (性能较高，但可能在崩溃时丢失少量已提交事务)。 innodb_flush_method 参数则控制数据页刷盘的具体方式，例如是否绕过操作系统缓存直接写入磁盘，以满足不同的性能和可靠性需求。 通过调整这些刷盘策略，用户可以在数据安全性和性能之间进行权衡，根据实际业务场景选择合适的配置。

最后，虽然 Binlog (二进制日志) 的主要用途是用于数据库的主从复制和时间点恢复，但它也间接地为数据持久性做出了贡献。 Binlog 记录了数据库中所有的数据变更操作 (逻辑操作，例如 SQL 语句)，这些日志可以用于数据库的备份和恢复，特别是当需要进行全量或增量备份，或者需要恢复到某个特定的时间点时，Binlog 就显得至关重要。 虽然 Binlog 的关注点和 Redo Log 略有不同 (Redo Log 侧重于崩溃恢复，Binlog 侧重于时间点恢复和复制)，但它们都为确保数据的长期安全性和可恢复性提供了重要的支持。

总结来说：MySQL InnoDB 通过 Redo Log + WAL 策略 保障事务提交的修改能够被可靠地记录下来， Doublewrite Buffer 增强了数据页写入的可靠性，Flush to Disk 机制 提供了灵活的刷盘控制，而 Binlog 则从更广泛的层面支持数据备份和时间点恢复。 这些机制相互配合，共同构建了持久性保障体系。

四、Consistency（一致性）

事务必须保证数据库从一个一致性状态转变到另一个一致性状态。一致性是指数据库的完整性约束没有被破坏。例如，主键唯一性、外键约束、CHECK 约束等。

  • 约束 (Constraints): MySQL 支持各种约束，如主键 (PRIMARY KEY)、外键 (FOREIGN KEY)、唯一键 (UNIQUE)、非空 (NOT NULL)、检查约束 (CHECK) 等。这些约束在数据写入时被强制执行，确保数据满足预定义的规则。
  • 触发器 (Triggers): 触发器是与表关联的存储程序，在特定事件 (如 INSERT、UPDATE、DELETE) 发生时自动执行。触发器可以用于实现更复杂的业务规则和一致性检查。
  • 应用程序逻辑: 虽然 MySQL 提供了约束和触发器，但最终的数据一致性也需要应用程序逻辑来保证。例如，业务逻辑需要确保事务操作符合业务规则，才能维持数据库的一致性状态。

其实对于一致性来说，它是其他三者（原子性、隔离性、持久性）的综合结果，辅以数据库约束和应用校验来共同保障最终一致性。

总结

MySQL通过以下核心机制实现ACID：

ACID特性核心机制关键组件
原子性Undo Log + 事务状态管理Undo Log、事务控制块
一致性约束 + ACID协同主键、外键、触发器
隔离性MVCC + 锁 + Next-Key LocksRead View、行锁、间隙锁
持久性Redo Log + Doublewrite BufferRedo Log、双写缓冲区

我们经常说的最终一致性是其他三个特性协同作用的结果，而非独立机制。当你理解了这些底层原理将会有助于优化事务设计（如合理选择隔离级别）和故障排查（如分析锁冲突）。

avatar
文章
阅读
粉丝