第1章 岗位能力画像与简历优化模板
数据库内核高级工程师面试，首先需要清晰定位自己的岗位能力边界。本章拆解核心能力画像，并提供一份可直接套用的简历优化模板，帮助你在简历筛选阶段就脱颖而出。
关键词+量化成果重构简历，提升30%以上面试邀约率。岗位能力画像
| 能力维度 | 核心技能点 | 简历关键词 |
|---|---|---|
| 存储引擎 | B+树、LSM-Tree、页管理、缓存策略 | 内存池、预写日志（WAL）、压缩、MVCC |
| 事务与并发 | ACID、隔离级别、锁协议（2PL/OCC）、死锁检测 | 多版本并发控制、乐观锁、封锁粒度、意向锁 |
| 查询优化 | 代价模型、算子流水线、索引选择、物化 | 统计信息、动态规划、Join排序、向量化执行 |
| 恢复与高可用 | redo/undo、检查点、主从同步、故障转移 | AOF、Raft/Paxos、租约、脑裂防护 |
| 性能调优 | 火焰图、perf、sysbench、TPC-C | 热点消除、锁竞争、NUMA优化、预读 |
| 分布式 | 分片、一致性哈希、分布式事务（2PC/3PC） | 全局时钟、动态rebalance、弹性扩缩容 |
简历优化模板
① 个人信息：姓名+电话+邮箱+Github/博客链接；
② 技术栈：按“精通/熟悉/了解”分级，不要罗列无关技能；
③ 工作经历：倒序，每段用STAR提炼2-3个亮点；
④ 项目经验：选3个内核相关项目，每个200字以内；
⑤ 成果量化：用
动作+指标+对比格式。• 写“参与数据库内核开发”而不写具体模块；
• 堆砌技术名词但无量化成果（如“使用了多版本并发控制”应改为“实现了基于时间戳的MVCC，读写冲突降低60%”）；
• 项目背景不明，面试官无法判断难度。
关键词清单
按能力维度精选30个高频命中词，建议在简历中自然嵌入：
- 存储：B+树分裂、LSM compaction、write stall、page cache、buffer pool、预写日志
- 并发：ReadCommitted、Serializable、行锁升级、锁等待超时、死锁回滚、MVCC快照
- 查询：索引下推、hash join、materialize、filter selectivity、并行扫描、limit pushdown
- 恢复：checkpoint、redo apply、undo truncate、recovery后的空闲空间管理
- 调优：innodb_io_capacity、tcmalloc、numa、hugepage、adaptive hash index
- 分布式：gossip、成员变更、prepared state、transient state、跨分片查询
成果量化句式模板
动词 + 具体技术 + 做了什么事 + 前后对比（量化指标）示例：
“重构B+树索引页分裂算法，将插入延迟从平均2.3ms降至1.1ms（降低52%），并减少30%锁竞争。”
“实现基于磁盘的Hash Join算子，支持TPC-H Q5执行时间从45s缩短至18s（提升60%）。”
“设计checkpoint自适应调度，消除高峰期IO抖动，P99写入时延稳定在5ms以内。”面试问答卡片
问题1：请介绍一下你负责过的数据库内核项目，以及你在其中的角色。
🎯 考察点：项目贡献真实性、对系统架构的理解深度、量化思维。
回答框架：使用STAR（背景→任务→行动→结果），重点讲你个人解决的核心难点，避免只说团队成就。
示例回答（约85字）：“在xx分布式数据库项目中，我负责存储引擎层。针对高并发写入下WAL写放大问题，设计组提交+异步fsync策略，将事务写入吞吐从8k tps提升至22k tps，同时保证crash-safe。”
可能追问：
• 组提交的窗口大小如何调节？
• 异步fsync下如何保证不丢数据？
• 如果系统突然断电，你的设计如何恢复？
问题2：你对B+树和LSM-Tree有什么理解？在什么场景下选择哪种？
🎯 考察点：底层数据结构认知深度、场景决策能力。
回答框架：先对比两者核心差异（读快 vs 写快），再结合工作负载（point查询/范围扫描/写入密集）给出选择理由。
示例回答（约95字）：“B+树随机读性能优秀（O(logN)），适合OLTP点查；LSM-Tree写入吞吐高（顺序写），适合写入密集型或日志场景。但LSM存在Compaction写放大和读放大，需要通过level大小、并行compaction等调优。在xx项目中我采用分层compaction将写放大从20倍降为8倍。”
可能追问：
• LSM中 leveldb vs rocksdb compaction策略区别？
• B+树在并行索引扫描时如何避免锁冲突？
• 实际项目中遇到过写老化吗？如何解决？
问题3：假设你发现一条SQL执行计划走了全表扫描，你会如何排查并优化？
🎯 考察点：查询优化实站能力、系统思维。
回答框架：①确认瓶颈（explain/analyze）→②检查统计信息是否准确（ANALYZE TABLE）→③索引是否缺失/未使用（索引选择）→④评估改写SQL或添加hint→⑤考虑修改join order或引入物化视图。
示例回答（约90字）：“首先用EXPLAIN ANALYZE查看实际执行时间与行数，发现join顺序错误导致中间结果膨胀。接着更新统计信息，结果未变，于是强制指定join顺序并创建覆盖索引，扫描行数从200万降为5000，查询从12s降到0.2s。”
可能追问：
• 统计信息过时导致选择错索引，如何自动检测？
• hint和optimizer之间的权衡？
• 对于大数据倾斜，你有什么调优手段？