事务的 ACID 特性是什么？

核心回答

ACID 是数据库事务的四项性质，用来处理一组操作执行到一半失败、多个事务同时修改数据，以及提交后发生故障的问题。

• 原子性（Atomicity）：事务中的修改作为一个整体提交或撤销，不能留下只提交一部分的结果。它强调的是这组操作的整体效果，不是说事务内部只有一条指令。
• 一致性（Consistency）：事务执行前后，数据都应满足既定约束和业务规则。例如唯一编号不能重复、无手续费转账前后资金总额不变。数据库约束和正确的业务逻辑需要共同保证这一点。
• 隔离性（Isolation）：控制并发事务之间的相互影响，规定可以看到其他事务的哪些修改，以及如何协调冲突。实际保证与隔离级别有关，不能笼统理解成“所有事务永远互不影响”。
• 持久性（Durability）：事务一旦成功提交，其结果应在数据库所承诺的故障条件下保留下来，可以在崩溃后恢复。它关注已经提交的结果，而原子性关注是否留下半个事务。

可以用一句话记忆：A 管整笔成功或撤销，C 管结果符合规则，I 管并发影响，D 管提交后能恢复。

用转账串起四项性质

假设 A 有 1000 元、B 有 500 元，现在 A 向 B 转账 100 元，不计手续费。

1. 把“A 扣 100”和“B 加 100”放在一个事务中。如果第二步失败并回滚，A 的扣款也要撤销；这体现原子性。
2. 成功后 A 为 900、B 为 600，总额仍是 1500，并且满足约定的余额限制；这体现一致性。如果程序给 B 加成了 90，数据库也未定义相应约束，事务仍可能成功提交，说明事务不能替应用识别所有业务错误。
3. 如果此时还有其他转账同时扣 A 的余额，就需要合适的隔离和并发控制，避免基于旧余额相互覆盖。在至少读已提交的隔离级别下，其他事务也不能读取这笔转账尚未提交的修改；这体现隔离性解决的问题。
4. 数据库按持久化提交策略确认成功后，随即发生进程崩溃，重启仍能恢复这笔转账；这体现持久性。

这里的“整体”指同一个事务覆盖的操作。如果两个更新各自自动提交，或者其中一步是外部支付接口调用，不能直接用一个本地数据库事务承诺整个业务的 ACID。

常见追问

一致性是不是“所有人立即读到最新数据”？

这里的一致性指数据满足约束和业务不变量。查询是否能读到其他事务刚提交的修改，主要取决于隔离与读取规则；它也不等于分布式系统里各副本始终具有相同数据。

有 ACID，为什么还要选择隔离级别？

数据库提供的并发保证有强弱之分。读已提交禁止脏读，但同一事务的两次查询仍可能读到不同的已提交值；可串行化要求并发执行的效果等价于某个串行顺序，也不意味着实现上必须让所有事务逐个执行。业务要根据不变量选择隔离、锁或条件更新等手段。

持久性是否意味着数据永远不会丢？

持久性需要明确故障模型和配置。例如 MySQL/InnoDB 放宽日志刷盘策略，可能在故障时丢失已经确认提交的近期事务。磁盘彻底损坏、误删除等问题还需要备份和容灾，不能只靠事务处理。

参考资料