第2章 数据库内核核心知识体系梳理：存储引擎、索引结构、事务ACID、锁与并发控制
本章围绕数据库内核面试最高频的四大知识领域展开，帮助面试者建立体系化理解。每个知识点既是独立模块，又相互关联：存储引擎决定数据组织方式，索引结构决定访问路径，事务ACID与锁机制共同保证并发下的正确性。以下知识结构表梳理了各领域的核心考点与面试常见切入点。
核心知识体系总览
| 知识体系 | 核心考点 | 常见面试切入点 |
|---|---|---|
| 存储引擎 | B+树 vs LSM树；堆表 vs 索引组织表；WAL与刷盘策略 | 写放大、读放大、空间放大；引擎选型依据 |
| 索引结构 | B+树分裂合并；LSM树层级合并；哈希索引；位图索引 | 索引代价；聚簇索引 vs 二级索引；索引下推 |
| 事务ACID | 原子性实现（UNDO日志）；一致性约束；隔离性级别；持久性（REDO日志/WAL） | MVCC与快照隔离；脏读/不可重复读/幻读检测 |
| 锁与并发控制 | 两阶段锁（2PL）；意向锁；行锁 vs 页锁；死锁检测 | 锁升级；乐观锁 vs 悲观锁；隔离级别与锁的关系 |
面试回答框架图
以“对比B+树索引与LSM树索引”为例，右下角框架展示结构化的回答路径。面试时沿着路径逐层展开，每个节点控制在12字以内的短句，便于边写边讲。
面试问答卡片
卡片1：存储引擎与索引结构对比
面试问题：请解释B+树索引与LSM树索引的核心区别，并说明各自适用的业务场景。
面试官考察点：是否理解两种主流索引的数据结构与读写权衡；能否结合系统设计（如写放大）给出选型判断。
回答框架：1. 数据结构差异（有序平衡树 vs 多层合并树）→ 2. 性能特征（读稳定 vs 写吞吐高）→ 3. 写放大与空间放大 → 4. 典型场景（OLTP vs 日志/时序）。
简短示例回答：（85字）B+树采用有序叶子链表，读延迟稳定，适合OLTP点查；LSM树将随机写转为顺序写，写吞吐高但读需合并多层，写放大3~10x。MySQL InnoDB用B+树，RocksDB用LSM树。选型时关注写密集程度与读QPS要求。
可能追问：如何减少LSM树的写放大？Block Cache与Bloom Filter如何配合？
卡片2：事务ACID实现原理
面试问题：请简述事务的ACID特性，并重点解释数据库如何实现持久性（Durability）。
面试官考察点：是否了解WAL（Write-Ahead Logging）与REDO日志；能否区分持久性与原子性的实现机制。
回答框架：1. ACID定义（原子性、一致性、隔离性、持久性）→ 2. 持久性依赖WAL（先写日志再写数据页）→ 3. REDO日志结构与恢复流程（Checkpoint + 重放）→ 4. 刷盘策略（fsync频率、group commit）。
简短示例回答：（75字）WAL保证：事务提交前将REDO日志持久化到磁盘，数据页可延迟刷出。若系统崩溃，启动时扫描REDO日志，重放未刷盘的操作。MySQL InnoDB的REDO log采用循环写+checkpoint，保证故障恢复后数据不丢。
可能追问：WAL与UNDO日志如何配合？组提交（Group Commit）如何优化性能？分布式事务中的两阶段提交与WAL关系？
卡片3：锁与并发控制
面试问题：请解释两阶段锁协议（2PL）如何保证事务的隔离性？它与MVCC的关系是什么？
面试官考察点：是否理解2PL的扩张与收缩阶段；能否对比2PL与MVCC在并发控制上的不同思路。
回答框架：1. 2PL定义（加锁阶段只加锁不放锁，解锁阶段只放锁不加锁）→ 2. 保证可串行化调度（SS2PL）→ 3. 可能产生死锁（需死锁检测或预防）→ 4. MVCC用多版本替代锁，实现快照隔离→ 5. 实际系统（如InnoDB）混合使用2PL+MVCC。
简短示例回答：（90字）2PL通过事务结束时统一释放锁避免级联回滚，保证冲突可串行化。MVCC通过保留数据旧版本使读不阻塞写，实现RC/RR隔离。InnoDB在REPEATABLE READ下使用MVCC做快照读，写操作仍通过2PL加行锁，混合使用兼顾性能与正确性。
可能追问：什么是严格2PL（SS2PL）？如何解决幻读？意向锁在2PL中的作用？
项目实战案例
以下项目模板适用于简历中“存储引擎优化”相关经历，面试官常以此考察候选人对事务、锁、索引落地的综合理解。
| 项目要素 | 内容 |
|---|---|
| 项目名称 | 分布式KV存储引擎的事务与索引优化 |
| 业务背景 | 电商订单中心日均写入10亿条，需支持跨行转账（分布式事务）与实时订单查询。原系统写放大严重，且RR隔离级别下幻读频繁。 |
| 规模指标 | 100+物理节点，单节点写入2万 QPS；数据总量10TB+；P99延迟<20ms。 |
| 技术栈 | C++17、RocksDB（LSM-Tree）、Paxos/Raft、WAL、MVCC、SQLite兼容层 |
| 核心难点 | ① 写放大控制：Leveled vs Universal compaction参数调优；② 分布式事务隔离：基于MVCC的SI + 冲突检测；③ 锁粒度优化：行锁 vs 间隙锁自动升级策略。 |
| 面试高频追问 | 如何设计compaction策略平衡写放大与读性能？WAL刷盘频率与group commit如何配置？MVCC中旧版本怎么回收（GC策略）？ |
| 可迁移回答话术 | “我在该项目中主要负责存储引擎层的性能调优。核心思路是分析系统瓶颈：先通过火焰图定位写放大过高，再对比不同compaction策略的放大系数，最终选用Leveled compaction + 调大level0文件阈值，使写放大从15倍降至5倍，同时搭配Bloom Filter保证点查命中率在99%以上。” 该话术突出“分析→实验→量化收益”的工程思维，可迁移到任何存储优化场景。 |