第1章 岗位能力画像与简历优化模板
本章定位：数据库内核负责人岗位面试，面试官首先通过简历判断候选人的能力边界与岗位匹配度。本章拆解大厂对该岗位的隐性能力要求，提供可直接套用的简历结构、关键词清单与成果量化句式，帮你从“做过”到“讲透”，在简历阶段就建立技术可信度。
岗位能力画像维度
| 能力维度 | 能力描述 | 核心要求 |
|---|---|---|
| 内核架构设计 | 理解数据库整体架构分层，能设计可扩展、高内聚低耦合的内核模块 | 模块划分、接口抽象、可测试性、版本演进 |
| 存储引擎开发 | B+ Tree / LSM-Tree 实现、缓存管理、WAL、MVCC、数据持久化 | 数据结构、磁盘I/O模型、事务ACID、崩溃恢复 |
| 查询优化器 | 代价模型、统计信息采集、Join 顺序重排、执行计划生成与缓存 | 优化算法、基数估计、计划缓存、CBO/RBO |
| 分布式系统 | 分布式事务（2PC/Percolator）、一致性协议（Paxos/Raft）、分片与复制 | 共识算法、MVCC 冲突处理、分布式死锁检测 |
| 技术领导力 | 技术评审、团队梯队建设、跨团队协作、技术规划与落地 | Code Review 机制、架构决策、人才评估、OKR 拆解 |
关键词清单与成果量化句式
| 能力维度 | 简历关键词 | 成果量化句式（直接用于简历） |
|---|---|---|
| 内核架构 | 分层架构、模块化、解耦、可扩展、接口抽象 | 主导设计存储引擎分层架构，统一 3 种存储格式访问接口，迭代周期缩短 35% |
| 存储引擎 | B+ Tree、LSM-Tree、WAL、缓存命中率、Compaction | 优化缓存淘汰策略，缓存命中率从 82% 提升至 96%，读延迟降低 42% |
| 查询优化 | 代价模型、统计信息、Join 重排、计划缓存、基数估计 | 重构优化器代价模型，TPC-H 22 条查询平均耗时降低 45%，覆盖全部线上慢查询 |
| 分布式 | Raft、分布式事务、分片、一致性、故障恢复 | 引入 Raft 共识算法，节点故障恢复时间从分钟级降至 3 秒，可用性提升至 99.995% |
| 技术领导力 | 技术评审、团队培养、技术规划、Code Review | 建立技术评审机制，团队交付效率半年提升 30%，核心模块 Bug 率下降 60% |
简历结构建议： 采用「技术栈总览 → 核心项目（3 个左右）→ 个人贡献提炼 → 技术影响力」的结构。每个项目按 STAR 展开，成果必须带量化指标。关键词覆盖上述 5 个维度，避免通用词如“熟悉”“了解”，改用“主导设计”“重构”“优化”“引入”等强动作词。
面试问答实战
🎯 面试问题 1
请描述你主导设计的一个数据库内核模块的架构，并说明关键决策点。
📋 面试官考察点
- 架构设计能力：模块划分、接口抽象、扩展性
- 技术深度：是否理解底层原理，而非 API 调用
- 决策逻辑：在性能、复杂度、可维护性之间的权衡
🧭 回答框架
“背景 → 方案对比 → 选型决策 → 落地效果” 四步法，每个步骤用一句话讲清“为什么选 A 而不是 B”。
💡 示例回答
我主导了 XX 数据库存储引擎的架构升级。针对混合负载场景，对比 B+ Tree 和 LSM-Tree 后，采用分层存储：热数据用 B+ Tree 保证点查，冷数据用 LSM-Tree 优化写入。统一缓存管理层，点查性能提升 40%，写入吞吐提升 2 倍。
❓ 可能追问
- 热冷数据如何界定和迁移？延迟如何控制？
- 缓存一致性问题怎么解决？Write-through 还是 Write-back？
- 为什么不做一种融合索引结构，而是保持两层？
⚠️ 避坑提醒
- 不要只讲结果不讲决策过程，面试官想看你的思考逻辑
- 主动说明方案的局限性和取舍，体现架构格局
- 用“