企业官网建设流程全解析

先给一句话简述（面试直接默写版）

• A 原子性 Atomicity：事务是不可分割的最小单元，要么全部成功，要么全部失败回滚，不会出现做一半的情况。
• C 一致性 Consistency：事务执行前后，数据库的数据约束、业务状态始终合法，从一个一致状态变到另一个一致状态。
• I 隔离性 Isolation：多个并发事务之间互相隔离，一个事务的修改，在提交前对其他事务不可见（由隔离级别控制强弱）。
• D 持久性 Durability：事务一旦提交成功，修改的数据永久落地，宕机、断电也不会丢失。

重点：一致性是最终目标，原子、隔离、持久是实现一致性的三个手段。很多人容易搞反这个逻辑！

深度逐个解析（结合转账经典例子：A 给 B 转 100，A-100，B+100）

1. 原子性 Atomicity

含义：事务内多条 DML 是一个整体，不允许部分提交。

• 转账：A 扣钱成功，B 加钱时报错 → 必须全部回滚，A 的钱恢复，不能出现钱凭空消失。
• 实现机制：undo log（回滚日志）执行 SQL 前，先把修改前的数据快照写到 undo log；事务失败时，依靠 undo log 反向回滚；提交成功后 undo log 可以清理。

注意：原子性是 “失败能回滚”，原子性本身不解决并发问题。

2. 一致性 Consistency（最难理解，面试高频坑点）

含义：数据库的完整性约束不能被破坏，包含：主键唯一、外键约束、字段非空、唯一索引、业务层面数据平衡。

• 转账例子：转账前后总金额不变（A+B 总和不变），这就是业务一致性；不能出现 A 扣了 100，B 没加上，总金额变少。
• 区分：
  • 原子性保证：失败就回滚，不会半完成
  • 隔离性保证：并发的时候不乱改
  • 持久化保证：提交后不丢 三者一起保障最终的一致性。

❌ 误区：一致性不是 “数据不能变”，而是变化之后依然符合规则。 ❌ 误区：一致性≠隔离性。就算只有一个事务串行跑，没有并发（隔离不存在），依然需要原子性保证一致性。

3. 隔离性 Isolation

含义：并发事务之间的可见控制，防止并发带来脏读、不可重复读、幻读。 数据库没办法做到完全隔离（串行化性能极差），所以分出 4 个隔离级别，隔离级别越高，并发性能越差。 依赖：MVCC + 锁机制 + read view（InnoDB） 并发三大问题：

1. 脏读：读到别的事务未提交的数据（对方后面回滚了，你读到脏数据）
2. 不可重复读：同一个事务内，两次读同一行，中间被别的事务修改并提交，两次结果不一样（针对行数据修改 update）
3. 幻读：同一个事务，两次范围查询，别的事务插入 / 删除了新行，行数变了（针对insert/delete，范围查询）

4 个隔离级别（MySQL InnoDB）

1. 读未提交 READ UNCOMMITTED：允许脏读，几乎不用
2. 读已提交 READ COMMITTED（RC，Oracle 默认）：解决脏读，存在不可重复读、幻读
3. 可重复读 REPEATABLE READ（RR，MySQL InnoDB 默认）：解决脏读、不可重复读；InnoDB 通过间隙锁 + MVCC，解决了幻读
4. 串行化 SERIALIZABLE：最高隔离，加读锁，所有事务串行执行，无并发问题，性能最低

一句话：隔离性就是控制 “别的事务改的数据，我能不能看见”。

4. 持久性 Durability

含义：事务 commit 成功后，修改一定永久保存，就算数据库宕机、服务器断电、崩溃，数据也不会丢。

• 实现机制：redo log（重做日志）MySQL 不是改完磁盘数据页再提交，而是先写 redo log（WAL 预写日志），先保证日志落盘，再异步刷脏页到磁盘。 宕机重启后，MySQL 扫描 redo log，把已经提交、但是还没刷到磁盘的数据重做恢复。

关键点：WAL 机制就是为了保障持久性，同时提升性能，避免每次事务直接刷磁盘。

✅ 核心关系梳理（面试加分）

目标：一致性 C支撑手段：

• A 原子性：故障场景，失败回滚，避免半事务
• I 隔离性：并发场景，事务之间互相干扰控制
• D 持久性：提交之后，数据不丢失

底层两大日志分工（InnoDB）

• undo log → 原子性 + MVCC 快照读
• redo log → 持久性

🧠 速记口诀（你偏好的迷你版）

原子不可分，undo 可回奔；

约束守一致，目标是根本；

并发靠隔离，锁与 MVCC；

持久 redo 稳，提交不丢本。