---
name: database
description: 数据库方向出题：关系型内核与存储引擎、索引与事务、SQL 优化、分布式数据库、NoSQL 选型、DBA 运维与高可用。岗位或简历涉及数据库内核、DBA、存储引擎、数据平台时加载。
keywords: [数据库, DBA, 数据库内核, 存储引擎, MySQL, InnoDB, PostgreSQL, 索引, 事务, MVCC, SQL 优化, 分布式数据库, TiDB, OceanBase, Redis]
layer: domain
---

## 岗位职责与考察重点

数据库方向的岗位分三类，考察重点差异很大。数据库内核开发（OceanBase、TiDB、达梦、云厂商 RDS 团队等）考的是存储引擎内部：B+ 树与 LSM 的读写放大、MVCC 的实现细节、redo/undo/binlog 的写入顺序、优化器的逻辑与物理优化、Raft 与两阶段提交，通常还会有 C++/Rust 手撕与 GDB 调试问题。DBA 与数据库运维考的是生产环境：主从复制与延迟、高可用切换、备份恢复演练、慢查询治理、大表变更、分库分表与迁移、国产数据库替换。后端开发中"偏数据库"的岗位以及数据平台岗位则考 SQL 优化、事务与锁的业务影响、存储选型。

校招候选人主要被考 InnoDB 原理（索引、事务、锁、日志）与基础 SQL 优化能力，内核岗会加上数据结构与操作系统功底；社招 DBA 必须有真实的故障处理与变更经历，内核岗必须读过某个引擎的源码并能说出设计取舍。

面试官最在意三件事：第一，能否把索引、锁、日志、复制这些机制串成一个"一条 UPDATE 从执行到主从落盘"的完整链路；第二，遇到慢查询、锁等待、复制延迟、主库故障时的排查顺序与工具，而不是背概念；第三，对数据安全的敬畏：备份是否演练过、大表变更是否评估过、切换是否会丢数据。

## 主题

### B+ 树与 InnoDB 存储结构
- 阶梯：为什么索引用 B+ 树、和 B 树的差别 → 聚簇索引与二级索引、回表与覆盖索引、页的结构 → 一张大表插入变慢、页分裂与碎片怎么观察与处理 → 主键选自增还是 UUID、什么场景该用 LSM 引擎
- 好题：一张按 UUID 做主键的订单表，写入越来越慢、空间比预期大一倍，原因是什么？你会怎么验证并迁移到新主键方案？迁移期间读写怎么保证不中断？
- 危险信号：B+ 树只答"矮胖"；不知道二级索引叶子存的是主键；回表只知道名词说不出何时代价大。
- 期望信号：能画出聚簇索引与二级索引的关系；知道页分裂、填充因子、change buffer；能对比 B+ 树与 LSM 的写放大与读放大。

### 事务、隔离级别与 MVCC
- 阶梯：ACID 各靠什么机制保证 → RC 与 RR 的差异、ReadView 的生成时机、undo 版本链 → 长事务导致 undo 膨胀与 history list 增长怎么发现与处理 → 隔离级别选 RC 还是 RR 的业务依据，MySQL 与 PostgreSQL MVCC 实现的取舍
- 好题：线上一个报表查询跑了两小时，之后 ibdata 暴涨、其他查询也变慢，这中间发生了什么？你怎么定位那个长事务并处理？以后怎么防？
- 危险信号：隔离级别只会背四个名字；MVCC 只说"多版本"说不出 ReadView 的判断规则；不知道长事务的危害。
- 期望信号：能说出 RR 下同一事务两次快照读一致的原因；知道 innodb_trx 与 history list length；能解释 PostgreSQL 的 vacuum 与 MySQL undo 的差异。

### 锁机制与死锁
- 阶梯：行锁、间隙锁、next-key lock、意向锁分别锁什么 → RR 下哪些语句会加间隙锁、唯一索引与非唯一索引的差异 → 一次死锁日志怎么读、锁等待超时怎么排查 → 减少锁冲突的业务改写与降到 RC 的取舍
- 好题：两个事务分别对不存在的行执行 SELECT ... FOR UPDATE 再 INSERT，结果死锁了，请解释锁的加法顺序；改成什么写法可以避免？
- 危险信号：认为行锁锁的是行数据而不是索引记录；说不出间隙锁的目的；死锁只答"重试"。
- 期望信号：知道锁加在索引上、无索引时锁全表；能读 SHOW ENGINE INNODB STATUS 的死锁段；有业务层顺序化或拆分事务的方案。

### 日志体系与崩溃恢复
- 阶梯：redo、undo、binlog 各解决什么问题 → 两阶段提交的顺序与 crash 后的恢复规则、刷盘参数的含义 → 数据库崩溃后启动慢、或主从数据不一致怎么判断是哪一环 → 双 1 配置的性能代价与什么业务可以放宽
- 好题：innodb_flush_log_at_trx_commit 和 sync_binlog 都设成 1 时性能下降明显，你会在什么业务上放宽到哪一档？放宽后掉电会丢什么？主从会不一致吗？
- 危险信号：分不清 redo 是物理日志、binlog 是逻辑日志；不知道两者写入顺序；把"双 1"当成必须。
- 期望信号：能讲清 prepare、写 binlog、commit 的顺序与恢复判断；知道组提交；能按业务容忍度选择刷盘策略。

### SQL 优化与执行计划
- 阶梯：执行计划里 type、key、rows、Extra 分别看什么 → 索引失效的常见原因、选择性与最左前缀、排序与分组走不走索引 → 一条慢查询的完整归因流程（索引、统计信息、锁、IO、参数） → 大表分页、count、深度 JOIN 的改写与何时该放弃在数据库里做
- 好题：一条 JOIN 三张表的查询在测试环境 50ms、线上 5 秒，表结构与索引一致，你怀疑哪些差异？按什么顺序验证？
- 危险信号：只会加索引；不知道统计信息会导致执行计划变化；深分页只答"用子查询"。
- 期望信号：能读执行计划并解释每一列；知道数据分布、统计信息、参数、缓存热度的影响；有延迟关联、游标分页等改写。

### 主从复制与延迟
- 阶梯：主从复制的三个线程与流程 → binlog 格式、并行复制的分组方式、GTID 的作用 → 复制延迟持续增长怎么定位是大事务、DDL、单线程还是从库 IO → 半同步的超时退化与业务读从库的一致性方案
- 好题：从库延迟从零突然涨到三千秒，你会先看什么？大概率的原因有哪几类？如果是一个大事务，为什么从库比主库慢那么多？怎么预防？
- 危险信号：只答"网络慢"；不知道从库默认单线程回放；不知道半同步会退化为异步。
- 期望信号：能说出 IO 线程与 SQL 线程各自的瓶颈；知道 writeset 并行复制；有大事务拆分与 DDL 低峰执行的规范。

### 高可用与故障切换
- 阶梯：主从、MHA/Orchestrator、MGR、PXC、云 RDS 高可用的差别 → 切换时如何保证数据不丢、如何防脑裂 → 一次主库宕机的处理时间线、切换后旧主如何处理 → 跨机房与多活的成本，什么业务值得
- 好题：主库机器突然掉电，你的高可用组件把从库提成主，五分钟后旧主机器恢复了，它上面可能有从库没收到的事务，你怎么处理这些数据？下次怎么避免？
- 危险信号：高可用只答"做主从"；不知道异步复制切换必然可能丢数据；不知道旧主要重做。
- 期望信号：能说出切换的每一步与失败点；知道 fencing 与 VIP/DNS 切换；有数据补偿与对账的方案。

### 备份、恢复与数据安全
- 阶梯：逻辑备份与物理备份的差别 → 增量备份与 binlog 的配合、恢复到任意时间点的过程 → 误删表或误更新怎么在最短时间恢复、恢复演练多久做一次 → 备份窗口、存储成本与 RPO/RTO 的取舍
- 好题：开发误执行了不带 WHERE 的 UPDATE，二十分钟后才发现，你怎么恢复这张表？如果这张表有 2TB 呢？整个过程业务要停多久？
- 危险信号：备份"每天一次全量"但没做过恢复；不知道闪回；恢复时间估不出来。
- 期望信号：有 xtrabackup 或克隆的经验；知道 binlog 闪回工具；能给出 RPO/RTO 数字并说清依据。

### 大表变更与分库分表
- 阶梯：为什么线上 DDL 危险 → Online DDL、gh-ost、pt-osc 的原理与副作用 → 分库分表的分片键选择、跨分片查询、全局唯一 ID → 数据迁移的双写、校验与回滚方案，什么时候该上分布式数据库而不是分库分表
- 好题：一张 5 亿行的表要加一列并回填默认值，你会用什么方式？各方式对主从延迟、磁盘空间、锁的影响是什么？中途失败怎么办？
- 危险信号：直接 ALTER TABLE；不知道 gh-ost 需要触发器或 binlog 的差别；分库分表只答"按 ID 取模"。
- 期望信号：能对比各工具的原理与代价；有变更评审流程；迁移有校验与回滚步骤。

### 分布式数据库原理
- 阶梯：为什么要分布式数据库、与分库分表的差别 → Raft 复制、Region 分裂、Percolator 两阶段提交与时间戳分配 → 热点 Region、大事务、跨 Region 查询的性能问题怎么排查 → 与 MySQL 的兼容性差异，什么业务不适合迁移
- 好题：一个自增主键的写入密集表迁到 TiDB 后写性能比 MySQL 还差，可能的原因是什么？怎么改？分布式事务的乐观与悲观模式各在什么场景出问题？
- 危险信号：只知道"可扩展"；说不出 Raft 与两阶段提交各解决什么；不知道热点问题。
- 期望信号：能讲清 TSO、Region、MVCC 版本在 KV 中的表示；知道 shard 键与随机化主键；能对比 OceanBase 与 TiDB 的架构差异。

### LSM 树与 KV 存储引擎
- 阶梯：LSM 为什么写快、读的代价在哪 → memtable、SSTable、compaction 的流程与 bloom filter 的作用 → 写放大、读放大、空间放大怎么度量与调优、compaction 抖动怎么处理 → 什么场景选 B+ 树、什么场景选 LSM
- 好题：RocksDB 服务出现周期性的写延迟尖刺，你怀疑什么？怎么用统计信息确认？在 leveled 和 tiered compaction 之间怎么选？
- 危险信号：LSM 只答"顺序写"；不知道 compaction 会占用 IO；分不清三种放大。
- 期望信号：能说出各层的合并策略；知道 write stall 的触发条件；有参数调优或分层存储的经验。

### NoSQL 与缓存选型
- 阶梯：Redis、MongoDB、HBase、Elasticsearch 各适合什么 → Redis 持久化与主从、集群分片、大 key 与热 key → 缓存与数据库不一致、Redis 内存打满、集群某节点慢的排查 → 什么数据该放数据库、什么该放缓存、什么该放搜索引擎
- 好题：Redis 集群一个节点 CPU 100%，其他节点正常，可能是什么原因？怎么找到那个 key？找到后有哪些处理方式？
- 危险信号：所有非关系数据都答 MongoDB；Redis 只知道"内存快"；不知道大 key 会阻塞。
- 期望信号：能按数据模型与访问模式选型；知道 redis-cli --bigkeys、slowlog、hotkeys；有拆 key 与本地缓存方案。

### 数据库内核开发专项
- 阶梯：SQL 从解析到执行经过哪些阶段 → 优化器的逻辑优化与物理优化、JOIN 算法、代价估算 → 一个查询优化器选错计划怎么调试、新增语法引起的规约冲突怎么排查 → 向量化执行、列存、HTAP 的取舍
- 好题：你要给数据库新增一种 JOIN 算法，需要改哪些模块？优化器怎么知道什么时候该选它？你怎么构造测试证明它在某类查询上更优且不引入错误结果？
- 危险信号：说不出解析、绑定、优化、执行的分层；不知道代价模型依赖统计信息；没有读过任何引擎源码。
- 期望信号：能画出查询处理流水线；知道 hash join、nested loop、sort merge 的适用场景；有源码阅读或贡献经历。

## 好题 / 坏题对比

- 坏：说说 MySQL 的四种隔离级别。
- 好：一个报表查询跑了两小时后 undo 暴涨、其他查询变慢，这中间发生了什么？你怎么找到并处理那个事务？
- 坏：主从复制的原理是什么？
- 好：从库延迟突然涨到三千秒，你先看什么、大概率是哪几类原因、如果是大事务为什么从库比主库慢很多？
- 坏：什么是分库分表？
- 好：5 亿行的表要加一列并回填默认值，你选什么方式、对主从延迟和磁盘的影响是什么、中途失败怎么办？

## 项目结合钩子

- 简历出现 MySQL 或 PostgreSQL 使用 → 追一次真实的慢查询归因过程与执行计划阅读。
- 简历出现"事务""并发扣减" → 追隔离级别选择、锁的范围、死锁经历与解法。
- 简历出现主从、读写分离 → 追复制延迟处理、读从库的一致性方案、切换经历。
- 简历出现分库分表或数据迁移 → 追分片键依据、跨分片查询、双写校验与回滚。
- 简历出现 Redis → 追持久化策略、大 key 热 key 处理、缓存一致性。
- 简历出现 TiDB、OceanBase 或国产数据库 → 追迁移遇到的兼容性问题、热点与事务模式选择。
- 简历出现 RocksDB、LevelDB 或自研存储 → 追 compaction 策略、放大指标、write stall 处理。
- 简历出现 DBA 经历 → 追备份恢复演练、大表变更流程、最严重的一次故障与复盘。

## 出题原则

- 把索引、锁、日志、复制串成"一条写请求从执行到主从落盘"的链路来考，单点概念只做开场。
- 每个主题必须落到排查场景并要求说出具体工具或视图（执行计划、innodb_trx、INNODB STATUS、slowlog、复制状态），考"做过"而非"听过"。
- 内核岗与 DBA 岗分开出题：内核岗追源码级设计取舍与数据结构功底，DBA 岗追变更流程、故障时间线与数据安全，不要用同一套题。
- 涉及数据安全的题（备份、变更、切换）必须追"演练过吗、失败怎么办"，没有演练的备份按没有备份评估。