数据库内核工程师

内核岗先讲模块定位：执行器（算子实现、向量化）、存储引擎（页面布局、索引结构）、事务系统（MVCC、锁管理、日志恢复）、优化器（规则/代价）。讲清你的贡献颗粒度：是重写了一个算子、优化了某瓶颈路径，还是设计了一个新特性；配合性能数据（TPC-H/TPC-C 某查询提升 X%）。内核面试会深入到代码级细节，讲你亲手写过的部分，准备好讲数据结构与边界条件。

B+ 树：矮胖结构（扇出大、树高 2-4 层）磁盘 IO 少，叶子链表利于范围扫描，读性能稳定可预测，适合读多写少；代价是随机写（页分裂）与写放大。LSM 树：写先入内存表再批量刷盘，顺序写吞吐极高；代价是读要查多层（布隆过滤器缓解）、compaction 的写放大与后台资源、空间放大。现代演化：B+ 树借鉴日志思想（redo、增量 checkpoint），LSM 优化读路径与 compaction 调度（RocksDB/leveled vs TiKV 的 Titan 类方案）。选型本质是读写负载比例的艺术。

核心思想：写不覆盖旧版本，读按快照选择可见版本，读写互不阻塞。Postgres：元组多版本链（xmin/xmax），快照由事务号区间决定，垃圾回收靠 VACUUM；长事务会抑制回收导致表膨胀。InnoDB：undo 链实现旧版本回溯，ReadView 决定可见性，Purge 线程回收。对比引出隔离级别实现差异：Postgres 可重复读靠快照天然防幻读，串行化用 SSI（冲突检测）；InnoDB 的 RR 是「可重复读+间隙锁防幻读」。能讲清「快照可见性判断算法」是深度分水岭。

WAL 原则：先写日志再写数据页（redo 先行），日志顺序写换取性能；checkpoint 定期把脏页刷盘以缩短恢复距离。恢复流程（ARIES 框架）：Analysis（从 checkpoint 扫出事务状态）→ Redo（重放所有已提交与未提交的修改，幂等重放）→ Undo（回滚未提交事务）。关键细节：日志须先落盘才能确认事务提交（组提交优化）、LSN 与页面的关系（page LSN 判断是否需要重放）、双一配置（innodb_flush_log_at_trx_commit=1 与 sync_binlog=1）的权衡。

流程：解析→逻辑计划（关系代数）→优化（规则改写：谓词下推、列裁剪、子查询去关联、join 消除）→物理计划（代价模型：统计信息估算基数、选择 join 算法 NL/hash/smoke、访问路径选索引还是全扫）。代价估算的难点：基数估计误差（直方图、采样、动态调整）会放大到 join 顺序选择。展示深度：讲一个你修过的 bad case（如统计信息过期导致的计划劣化、hint/plan management 的兜底），或对比 Cascades 框架与 Volcano 的实现差异。