事务的 ACID 特性详解

数据库中的 事务（Transaction） 是一组操作的集合，这些操作要么全部执行，要么全部不执行。为了保证事务可靠执行，必须满足 ACID 四大特性：

特性	英文缩写	简要说明
原子性	Atomicity	事务是一个完整的单位，要么全做，要么全不做
一致性	Consistency	事务执行前后，数据都必须保持一致性（遵循约束）
隔离性	Isolation	多个事务并发执行时，互不干扰
持久性	Durability	事务一旦提交，对数据的修改是永久性的，即使崩溃也不会丢失

---

1️⃣ 原子性（Atomicity）

要么全做，要么全不做

• 比喻：ATM 转账，钱扣了没到账，这是原子性问题。
• 举例：

  BEGIN;
  UPDATE account SET money = money - 100 WHERE id = 1;
  UPDATE account SET money = money + 100 WHERE id = 2;
  COMMIT;
  

  如果中间一条失败了，必须回滚之前操作。

---

2️⃣ 一致性（Consistency）

事务前后数据必须满足所有数据库约束，保持合法状态

• 比喻：账目不能多出来或少掉钱

• 举例：

  • 转账前：账户1有500元，账户2有300元，总额800元
  • 转账100后，总额仍为800元

  如果执行后总金额变成900元或700元，就违反一致性。

---

3️⃣ 隔离性（Isolation）

多个事务并发执行时，互不干扰

• 举例：两个事务同时修改同一条商品库存，如果不加隔离机制，可能导致超卖。

隔离级别	说明	问题防止
Read Uncommitted	可以读到未提交的数据	会脏读 ❌
Read Committed	只能读到已提交的数据	防脏读 ✅
Repeatable Read	一次事务中多次读取结果一致	防脏读+不可重复读 ✅
Serializable	严格串行执行，事务一个个来	最安全，防幻读 ✅

---

4️⃣ 持久性（Durability）

事务提交后，对数据的修改永久生效，即使断电、系统崩溃也不会丢失

• 举例：你提交了订单，系统突然宕机，重启后订单还在。
• 实现依赖：WAL 日志机制（Write Ahead Logging，先写日志再写磁盘）

WAL：写前日志（Write-Ahead Logging）

在对数据进行修改之前，先把修改的“意图”记录到日志中，再去真正修改数据页。

关键原则：

日志先行，数据后写；日志落盘，事务才算提交成功。

这个日志通常写在一个顺序 I/O 的文件里，写入快、稳定。

---

记忆小技巧（ACID）

字母	含义	关键词（助记）
A	Atomicity	原子炸弹：要么爆炸全部，要么不炸
C	Consistency	规则一致：前后一致，逻辑正确
I	Isolation	互相隔离：像独立房间互不干扰
D	Durability	写进石头里：一旦提交，永不丢失

---

https://github.com/0voice