database · git:20260908.a2a662c · 2026-09-08 · sha256 492a9bfcbacfcf65
database git:20260908.a2a662cA
Immutable. This exact content is served forever at /api/v1/blob/492a9bfcbacfcf65.
--- 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 岗追变更流程、故障时间线与数据安全,不要用同一套题。 - 涉及数据安全的题(备份、变更、切换)必须追"演练过吗、失败怎么办",没有演练的备份按没有备份评估。