# 1. LSM-Tree 与 B-Tree 的存储模型差异，写放大、读放大、空间放大的工程取舍与典型引擎（RocksDB vs InnoDB）？ A LSM-Tree 写放大低、读放大高，B-Tree 写放大高、读放大低 ✓ 正确答案 B LSM-Tree 读放大低、写放大高 C 两种结构的写放大和读放大完全相同 D RocksDB 使用 B-Tree，InnoDB 使用 LSM
# 2. LSM 合并策略，Tiered vs Leveled Compaction 的读写放大与延迟稳定性？ A 两者在所有指标上完全相同 B Tiered 读放大低、写放大高 C Leveled 写放大低、读放大高 D Tiered 写放大低、读放大高；Leveled 读放大低、写放大高 ✓ 正确答案
# 3. Buffer Pool 与页管理，LRU/Clock 淘汰、脏页刷盘与 checkpoint 如何共同影响读写放大与崩溃恢复？ A 每次写事务都必须立即把脏页刷到磁盘 B checkpoint 越频繁崩溃恢复越慢 C LRU 淘汰与脏页刷盘无关 D checkpoint 推进日志回收点，崩溃恢复从 checkpoint 的 LSN 开始重放 redo，三者在命中率、写放大与恢复时间间权衡 ✓ 正确答案
# 4. B+Tree 的页分裂/合并与写放大，与 LSM 相比，B+Tree 为什么读放大低但随机写放大高，定量如何比较？ A B+Tree 点查读放大低（约等于树高），随机写放大高；LSM 写放大低、读放大高 ✓ 正确答案 B B+Tree 写放大低、读放大高 C LSM 读放大低、写放大高 D B+Tree 与 LSM 的放大特性完全相同
# 5. RocksDB 的 MemTable/WriteBuffer 与 WAL 的写入路径（组提交、批量写） A 写入先进入 MemTable 并追加 WAL，组提交和批量写通过合并多个写请求的 fsync 提升吞吐 ✓ 正确答案 B 写请求直接写 SSTable，不需要 WAL C 每次写请求都独立 fsync 一次，吞吐最高 D MemTable 只用于读，不参与写入
# 6. 存储引擎的闩锁（latch）与事务锁（lock）有何本质区别？B+Tree 页访问为什么需要 latch，而 LSM 的并发模型有何不同？ A LSM 的 SSTable 是可变的，需要长期 latch B latch 与 lock 完全等价 C B+Tree 不需要 latch 也能安全并发 D latch 短持有保护物理结构、无死锁检测；lock 长持有保护逻辑一致性、有死锁检测，B+Tree 访问页用 latch，LSM 用不可变文件+版本化规避 ✓ 正确答案
# 7. SSTable 结构、Block Cache、Filter Block（Bloom Filter）的协同设计与性能影响？ A Bloom Filter 让不存在的 key 直接跳过文件，Index 定位块，Block Cache 复用已读块，共同降低读放大与 IO ✓ 正确答案 B Bloom Filter 会增大读放大 C Block Cache 与 Bloom Filter 无关 D SSTable 不含 Index 块，无法定位
# 8. 列式存储（Columnar Storage）的压缩（Run-Length/Dictionary/Delta）与向量化执行契合度？ A 压缩会破坏向量化执行 B 压缩后的数据必须完全解压成行式才能计算 C 列存数据离散，不适合 RLE 压缩 D 列存按列连续存储，RLE/字典/Delta 压缩降低数据量，且可在编码域直接向量化，契合度高 ✓ 正确答案
# 9. Undo Log 与 Redo Log 的分工，MVCC 版本链与崩溃恢复（WAL）分别依赖哪种日志，为什么 Redo 是物理、Undo 是逻辑？ A Undo 用于崩溃恢复，Redo 用于回滚 B Redo 物理记录页变更用于崩溃重放，Undo 逻辑记录撤销操作用于回滚与 MVCC 版本链 ✓ 正确答案 C Redo 是逻辑的，Undo 是物理的 D MVCC 版本链依赖 Redo
# 10. 自适应哈希索引（AHI）与 Bloom Filter 在加速点查时的边界，为什么 AHI 有内存与维护开销、命中率不稳定？ A AHI 与 Bloom Filter 都只适用于写密集场景 B AHI 无内存开销，命中率永远稳定 C Bloom Filter 会误判 key 存在，导致读放大明显增大 D AHI 用内存+维护成本换热点点查命中，命中率依赖访问模式；Bloom Filter 用少量误判换规避无效读盘 ✓ 正确答案
# 11. 存储层压缩，Page 级压缩、前缀压缩与字典编码在列存/行存的成本收益，压缩与随机更新的矛盾如何解决？ A 压缩后无法原地定位修改，需解压改完再重压缩，可用日志式/追加式更新或冷热分层缓解 ✓ 正确答案 B 压缩与随机更新完全兼容，无需处理 C 行存比列存更利于压缩 D 字典编码只适用于高基数列
# 12. InnoDB 的索引组织表，聚簇索引与二级索引的回表？ A 回表一定会降低性能但无法避免 B 二级索引叶子直接存整行，无需回表 C 聚簇索引只能一个，二级索引也只有一个 D 聚簇索引叶子存整行，二级索引叶子存索引列+主键，二级索引查询需回表取整行，覆盖索引可避免回表 ✓ 正确答案
# 13. 数据库页大小与 IO 对齐（4K/8K/16K）对读写性能的影响 A 页大小与 IO 对齐无关 B 页大小需与磁盘/文件系统块对齐，大页利于顺序吞吐与缓存率，小页利于随机点查精度与缓存粒度 ✓ 正确答案 C 页越大随机点查越高效 D 页越小顺序扫描吞吐越高
# 14. 崩溃恢复如何利用 checkpoint 确定重放起点？redo 从哪个 LSN 开始、undo 如何回滚未提交事务？ A redo 必须从头重放全部日志 B redo 从 checkpoint 记录的 LSN 开始重放已提交修改，未提交事务依据 undo log 回滚 ✓ 正确答案 C checkpoint 记录了内存数据的全部内容，无需重放 D 未提交事务的修改不需要回滚
# 15. Bw-Tree、HOT 等新型索引结构分别针对 B+Tree 的什么问题（无锁并发、缓存友好、写放大）？工程落地为何有限？ A 新型索引已完全取代 B+Tree B Bw-Tree 用无锁+delta 更新针对并发，HOT 针对写放大/缓存，但实现复杂且与恢复/事务集成难，落地有限 ✓ 正确答案 C Bw-Tree 针对读放大而非并发 D HOT 只针对内存容量，不涉及写放大
# 16. 学习型索引（Learned Index, The Case for Learned Index Structure）的工程进展与适用范围？ A 学习型索引不需要误差上界保证 B 学习型索引可完全替代 B+Tree 且支持高并发更新 C 用模型学习 key 到位置的映射，需保证误差有界，适合静态只读数据，生产落地有限 ✓ 正确答案 D 学习型索引只适用于动态更新场景
# 17. 新硬件对存储引擎的挑战，NVMe SSD 与持久内存（PMEM）如何改变页缓存与 fsync 的工程假设？ A SSD 仍需严格顺序写才能高效 B NVMe 与 PMEM 对存储引擎设计没有影响 C PMEM 无需任何持久化屏障 D NVMe 缩小随机与顺序 IO 差距、PMEM 提供字节寻址持久化，都改变了页缓存与 WAL/fsync 的旧假设 ✓ 正确答案
# 18. 内存数据库索引，Hash 索引与跳表的应用？ A 跳表不支持并发 B Hash 索引支持范围查询 C Hash 索引等值点查 O(1) 但无序，跳表支持有序遍历与范围查询 O(log n)，按查询形态选择 ✓ 正确答案 D 内存数据库只能使用 Hash 索引
# 19. 对象存储作为数据库存储层的挑战（延迟、写入放大）与混合存储方案 A 混合存储无法解决对象存储的写放大问题 B 对象存储支持细粒度随机写，适合作为热存储层 C 对象存储延迟极低，适合热路径 D 对象存储高延迟、按对象不可变导致写放大，混合方案用热数据本地+冷数据对象存储缓解 ✓ 正确答案
# 20. 页内的行与记录如何布局（插槽数组、碎片）？页内碎片整理与合并对更新密集负载的影响是什么？ A 碎片整理对用户总是无感知的，应频繁执行 B 槽数组使记录无法移动 C 页内用槽数组+数据区使记录可移动，碎片整理与页合并提高空间利用率但会带来 CPU/IO 与并发开销 ✓ 正确答案 D 页合并与页内布局无关
