每年校招季我都会接触不少准备数据库方向笔试的同学看到最多的状态就是简历上写着“熟悉 MySQL”“了解索引优化”一碰到数据库管理工程师的笔试卷却在索引、事务、锁、备份恢复这些题目上翻车。网易这套 2018 校园招聘数据库管理工程师笔试卷出的题其实很有代表性它不一定考你背了多少概念而是考你有没有一个 DBA 的脑子数据出问题的时候你能不能快速定位、能不能给出可落地的恢复方案、能不能看懂一条 SQL 为什么会慢。这篇文章我不打算逐题报答案而是把这份试卷背后真正想筛的能力拆开配合典型题目场景和实操思路给准备走数据库管理方向的同学一份有参考价值的备考地图。1. 一份数据库管理工程师笔试卷到底在筛什么人1.1 写 SQL 的人和管理数据库的人完全是两种物种先想清楚一个前提数据库管理工程师不是让你来写业务 SQL 的。业务开发也会写 SQL但开发关心的是“这条查询结果对不对”DBA 关心的是“这条查询在生产环境会不会把库拖垮”。这两个视角完全不同笔试卷出题的时候也会刻意区分。比如同样面对一张订单表开发可能会写SELECT * FROM orders WHERE user_id 123能跑出结果就完事。但 DBA 看到这条语句脑子里会立刻弹出几个问题user_id 上有没有索引type 是不是 ALLrows 扫描了多少行Extra 里有没有 Using filesort如果这张表有几百万行这条语句会不会把 buffer pool 打穿有没有可能用覆盖索引减少回表所以你会发现校招笔试卷里很多题目表面上是考 SQL 语法实际考的是你有没有这种“性能敏感”和“故障敏感”的意识。你不需要有几年生产经验才能答题但你需要知道一个 DBA 看到问题时的思考路径是什么。1.2 从考点分布反推岗位能力模型虽然这份试卷具体题目每年的版本会有调整但知识板块的分布是有规律的。我根据带过的校招生和这些年看到的真题大致整理出下面这张能力地图知识板块考察目的典型题型SQL 基础与数据模型基本功是否扎实手写 SQL、范式判断、表设计索引与查询优化有没有性能意识复合索引选择、执行计划分析事务与锁机制并发控制的理解深度隔离级别、死锁场景分析备份恢复数据安全意识误删数据恢复方案设计高可用与架构视野是否局限在单机主从复制、容灾方案操作系统与网络基础排障能力下限端口、进程、磁盘 IO 相关题这里面有个容易被忽略的点数据库管理工程师的笔试卷不只是考数据库本身。操作系统、网络、存储这些周边知识也会占一定比例。原因很简单生产环境里数据库出了问题排查链路往往是从操作系统开始的。比如磁盘满了导致 MySQL 只读、网络抖动导致主从延迟、内存不足触发 OOM 导致实例重启。笔试考这些不是为了难为你而是为了确认你有没有能力在“数据库之外”找原因。1.3 2018 年这个时间点的特殊技术背景为什么要单独说年份因为校招笔试卷的考点其实紧跟当时的技术潮流。2018 年这个时间点有几个特点MySQL 5.7 是主流生产版本8.0 刚发布还没大规模铺开所以试卷里大量题目围绕 5.7 的行为展开比如半同步复制、GROUP BY 的排序逻辑、JSON 类型的支持。云数据库 RDS 开始普及但很多互联网公司核心库还是自建机房物理机所以传统 DBA 的硬核技能——mysqldump、xtrabackup、binlog 恢复、主从切换——依然是笔试重点。分库分表和分布式数据库概念开始热门但实际落地方案还不像今天这么成熟所以试卷里更多是考“水平拆分和垂直拆分的取舍”这类思维题很少考具体中间件操作。理解这个背景有什么用它能帮你判断笔试着重复习的重点应该放在“单机数据库的原理和运维”而不是上来就研究分布式数据库。很多同学看了一堆 TiDB、OceanBase 的资料结果基础题反而丢分这个方向就偏了。2. 索引与执行计划为什么这部分永远是大头2.1 最左前缀原则一道送分题怎么变成送命题索引类题目几乎是数据库笔试试卷里雷打不动的第一大户。其中最高频的考点就是复合索引的最左前缀原则。很多同学觉得这个简单但实际做题时换一个问法就懵。举一个典型题例表上有复合索引(a, b, c)下面几个查询哪些能用到索引WHERE a 1 AND b 2 AND c 3——全命中最理想。WHERE b 2 AND c 3——用不到因为没有从最左列开始。WHERE a 1 AND c 3——只能用a这一列c没法用索引过滤。WHERE a IN (1, 2) AND b 10 AND c 3——能用a和b的范围条件但c还是会失效。第 4 个例子是最容易答错的。原因是 B 树索引的匹配顺序是有方向的范围查询之后后续列无法继续用于精确定位。b 10一旦成为范围条件c就失去了参与索引匹配的机会。这就是很多人背了“最左前缀”四个字却没法解释“为什么会这样”的地方。另外一个容易被忽略的考点是排序。复合索引(a, b)不仅能加速WHERE a ?的查询还能让ORDER BY a, b直接走索引避免 filesort。笔试卷经常会问“下面这条语句能否避免 Using filesort”你只要记住索引列的顺序和排序方向一致才行ORDER BY a DESC, b ASC这种混着来的情况优化器往往做不到完美利用索引。2.2 执行计划的关键指标别把 explain 的结果当摆设如果说索引概念题是第一层那执行计划分析就是第二层。笔试不会让你真跑一条 SQL但它会给你一条 SQL 外加一个 explain 输出让你判断问题出在哪。这种题核心看四个字段type访问类型从好到差大致是const→eq_ref→ref→range→index→ALL。如果看到ALL意味着全表扫描这类 SQL 在生产环境基本会被 DBA 重点盯上。key实际用到的索引是哪个。如果为NULL说明没用到索引。rows预估扫描行数。这个数字越接近表的总行数问题越严重。Extra出现Using filesort或Using temporary是危险信号意味着查询需要额外的排序或临时表性能很难好。我见过最典型的题目是给出SELECT * FROM user WHERE age 20 ORDER BY create_time以及一个显示Using filesort的 explain 结果问怎么优化。这里有两个维度可以考虑如果age区分度不高加索引未必有显著收益但如果查询本身低频可以先建立(age, create_time)的复合索引让过滤和排序都能走索引。如果查询高频还可以考虑在create_time上单独建索引先排好序再回表过滤也行具体看统计信息。笔试面试里我一般建议你按这个路径答先做数据量级和业务频率的判断再给索引方案最后补充一句“上线前要在测试环境用真实数据量验证”。这样答出来比一上来就丢一个“加索引”的结论要专业得多。2.3 覆盖索引和索引下推能拉开差距的细节如果试卷有拔高题往往会从覆盖索引和索引下推这两个点出。覆盖索引意思是查询的所有列都在索引里不需要回表。举个例子表上有索引(user_id, status)查询SELECT status FROM order WHERE user_id 123因为user_id和status都在这颗索引树上直接遍历索引就能拿到结果省掉了一次主键回表。笔试里问“这条 SQL 为什么快”往往就是覆盖索引的功劳。索引下推Index Condition PushdownICP是 MySQL 5.6 引入的优化很多人没听说过。它的逻辑是在没有 ICP 之前存储引擎从索引中取出记录后要回表拿到完整行再由 Server 层判断其他条件有了 ICP可以在存储引擎层先把一部分条件过滤掉减少回表次数。举个经典例子复合索引(zipcode, lastname)查询WHERE zipcode 100000 AND lastname LIKE %张%。lastname LIKE %张%无法用索引匹配但 ICP 可以在读取索引记录时就用 LIKE 条件过滤掉大量无效数据再回表。笔试如果问你“ICP 有什么好处”核心答案就是减少回表次数降低 IO。能把这个细节写出来基本就能在众多候选人里拉开差距。3. 事务隔离级别与锁机制这类题怎么答才不丢分3.1 隔离级别背得下来但题还是不会做事务隔离级别这块面试笔试几乎是必考。但我发现一个普遍问题很多同学四句话背得滚瓜烂熟——读未提交有脏读读已提交解决脏读但会不可重复读可重复读解决不可重复读但可能幻读串行化最安全但性能差——可真给一个场景题就不知道怎么用了。原因在于没有理解每个隔离级别是“在性能和一致性之间做了哪种取舍”。更关键的是很多同学不知道 MySQL 的默认隔离级别是可重复读Repeatable Read而 Oracle、PostgreSQL 默认是读已提交Read Committed。这个差异在笔试里经常出现而且会直接影响后续锁机制和 MVCC 的答案。举个典型场景题事务 A 先读取了一行balance 100事务 B 修改这行变成 200并提交。请问在 RR 和 RC 下事务 A 再次读取这行分别看到什么RR 下因为快照读机制A 看到还是 100RC 下因为每次读都拿最新已提交版本A 会看到 200。这种题不需要背概念理解 MVCC 的多版本链就能答对。MVCC 是 MySQL InnoDB 实现隔离级别的核心机制笔试高频考点。它维护了一条版本链每行记录有多版本数据read view决定了事务能看到哪个版本。RR 下read view在第一次查询时生成整个事务复用RC 下每次查询都重新生成。所以 RR 下同样的查询得到一致的结果这就是快照读层面的“一致性读”。3.2 行锁、间隙锁、next-key lock 的典型场景MVCC 解决了快照读的隔离问题但更新操作是“当前读”需要真正的锁。这就引出了行锁、间隙锁、next-key lock 这些考点。很多校招生对锁的理解停留在“读锁和写锁”这个层面一旦笔试问到 InnoDB 的具体锁类别就乱了。这里需要清楚几个层次共享锁S 锁和排他锁X 锁最基础的锁类型一行记录可以被多个事务加 S 锁但 X 锁只能被一个事务持有。记录锁Record Lock锁住的是索引记录本身注意 InnoDB 是通过索引来锁行的不是直接锁物理行。间隙锁Gap Lock锁住索引记录之间的间隙防止其他事务在这个间隙插入新的记录用来解决幻读。Next-key Lock记录锁 间隙锁的组合锁住的范围是一个左开右闭区间(前一条记录, 当前记录]。典型笔试场景在 RR 隔离级别下数据库有 id 为 1、5、10 三行事务 A 执行SELECT * FROM t WHERE id 5 FOR UPDATE。这个语句会锁住id 5的记录行吗还会不会锁住(5, 10]和(10, ∞)的间隙答案是它会锁住 id10 这一行同时因为 RR 下默认用 next-key lock间隙(5, 10)和(10, 正无穷)也会被锁其他事务想插入 id8 或 id100 都会被阻塞。很多人不理解为什么“查不到的行”还要加锁。这就是 RR 隔离级别为了防幻读付出的代价。如果笔试题目问“数据库默认隔离级别下间隙锁会带来什么副作用”你可以答降低并发插入能力容易引发死锁这也是很多互联网公司把隔离级别从 RR 改成 RC 的原因之一因为 RC 下只存在记录锁间隙锁被禁用了死锁概率会明显下降。3.3 死锁分析题怎么把排查思路写到卷子上死锁是 DBA 工作中必须面对的问题笔试卷尽量不会出太复杂但一定会出一个典型场景两个事务各自持有一个锁又同时等待对方持有的锁。最常见的就是两条 UPDATE 语句顺序相反。事务 A 先更新 id1 再更新 id2事务 B 先更新 id2 再更新 id1。当两个事务并发执行时A 持有 id1 的锁在等 id2B 持有 id2 的锁在等 id1互相不肯放手InnoDB 检测到死锁后会选择回滚一个代价较小的事务。笔试遇到这种题答题的关键不是把死锁定义默写一遍而是给出一个完整的分析链条两个事务各自持有什么锁、正在等什么锁画一个等待环出来。如何从SHOW ENGINE INNODB STATUS的日志里发现死锁信息看LATEST DETECTED DEADLOCK部分。往业务层面怎么修统一 UPDATE 语句里条件的顺序保证所有事务按相同顺序访问行或者缩短事务持续时间减少锁持有的窗口。如果业务确实没法调整顺序可以在高峰期前通过SELECT ... FOR UPDATE预锁定目标行或者考虑降低隔离级别到 RC减少间隙锁带来的死锁可能性。这套答法能体现出你不是在背概念而是真的想过“如果我来值班我会怎么处理”。还有一个小细节在描述死锁时一定要提到 InnoDB 会通过检测机制而不是超时机制来处理大部分死锁死锁检测默认开启并且会把回滚代价较小的事务选为 victim。这个细节能加分。4. SQL 优化与慢查询排查笔试题背后的运维思维4.1 一道 SQL 优化题考察的其实是排查顺序数据库管理工程师岗位笔试基本不会绕过 SQL 优化这块。但这类题目并不单纯考“你会不会写高效 SQL”而是考你看到一个慢 SQL 之后脑子里有没有一条标准的排查链路。我建议所有准备笔试的同学把一个思路印在脑海里慢 SQL 出现后第一步永远是确认问题现象而不是急着改 SQL。比如这条 SQL 是偶发慢还是持续慢慢的时候系统整体负载如何有没有其他大查询并行表数据量最近有没有突增执行计划有没有变化是不是统计信息不准确导致走了错误索引很多校招生一看到慢 SQL 就回答“加索引”这是最典型的扣分项。真实生产环境里一条 SQL 变慢的原因可能很多统计信息过期导致执行计划偏离、锁竞争导致阻塞、磁盘 IO 抖动、查询缓存失效、或者网络延迟。不加判断直接加索引往往解决不了实际问题。如果笔试卷给的具体场景是“订单表 order 有 500 万行查询SELECT * FROM order WHERE user_id 123 ORDER BY create_time DESC LIMIT 20很慢怎么优化”我会这么拆解先看user_id是否有索引。如果没有全表扫描是必然的首选是加(user_id, create_time)复合索引让过滤和排序同时走索引。如果已经有索引但还慢看查询是否用到了回表。SELECT *意味着查询所有列即使索引命中也得回表拿数据。考虑改成覆盖索引只返回必要字段减少回表次数。如果业务允许考虑把LIMIT 20变成一个基于游标的翻页方式避免深分页问题比如用WHERE create_time 上次查询的最后一条时间来替代OFFSET。这种回答顺序展示的是“定位问题 → 分析原因 → 给方案 → 预估效果”的完整闭环比单纯丢一个方案扎实很多。4.2 慢查询日志与工具链笔试怎么考慢查询日志是 DBA 定位慢 SQL 的第一手数据。笔试卷可能不会直接考命令参数但会给你一个场景某天业务方反馈线上接口变慢你要怎么找出慢 SQL。我的建议是把以下概念理清slow_query_log开启开关long_query_time阈值。生产环境一般设 1 秒如果实例压力大可以调到 2 秒或 5 秒避免日志刷太多。log_queries_not_using_indexes可以记录没走索引的查询这在笔试里可以作为一个补充点提出来说明你有“提前发现隐患”的意识。日志拿到后可以用mysqldumpslow或pt-query-digest做聚合分析按执行时间、扫描行数排序筛选出真正需要处理的头部 SQL。笔试考这个点的意图是看你有没有“从海量日志里找到关键问题”的思路。回答时不需要很细节地背出每个参数但一定要能说清楚“谁的日志、怎么开启、达到什么阈值、如何分析”这样逻辑就完整了。4.3 分库分表概念题背后的架构思维2018 年前后的笔试分库分表开始频繁出现。这类题目通常是概念题加一点设计题。比如单表数据量到了几千万写性能下降要不要分库分表怎么分这里有一个很关键的判断分库分表是最后手段不是第一选择。笔试卷里如果考这个正确答案的第一步往往是先排除其他可能性归档历史数据、优化索引、升级硬件、读写分离。很多同学上来就说“按 user_id 分 64 张表”忽略了业务场景反而暴露了“没有真实运维经验”的问题。如果确实要分需要说清楚两个方向水平拆分同一张表的数据按照某个分片键拆到多张表。比如订单表按order_id哈希分片每个分片存不同范围的数据。优点是水平扩展能力强缺点是跨分片的 JOIN、聚合、事务会变得复杂。垂直拆分把不同的业务列拆到不同的表或库里。比如把热点字段和非热点字段分开。优点是单表变瘦、缓存命中率提高缺点是拆分后查询逻辑变复杂。答这种题的时候如果能顺带提一句“分片键的选择特别重要要尽量让查询带上分片键避免跨分片扫描”会显得你有落地思考。因为真实场景里分片键选错会导致大量广播查询性能比不分片还差。5. 备份恢复与高可用笔试里偏“架构”的题目怎么切入5.1 从“误删数据”场景看备份恢复能力数据库管理工程师和开发工程师最大的区别就是你对“数据没了”这件事有多敏感。笔试卷里大概率会出一道备份恢复的题最常见的场景是某天凌晨三点一个同事执行了一条DELETE或者DROP TABLE误删了核心表数据你作为 DBA怎么处理这道题没有标准答案但有一条比较完整的思路线先冷静别让问题扩大。如果误删是刚发生的立刻检查 binlog 是否开启。MySQL 生产环境一般都会开启log_bin如果开启了恢复就有戏。确认全量备份的情况。上次全备是什么时候用mysqldump还是xtrabackup如果全备存在可以起一个临时实例把全备恢复到误删前一秒的状态。用 binlog 做增量追加。全备恢复到某个时间点之后把误删时刻之前的 binlog 重放到临时实例利用mysqlbinlog --stop-datetime或者--stop-position精确截断。最后再把临时实例里的这部分数据导回生产库。这个流程里有几个笔试高频坑点一定要提“先停止业务写入或者把表置为只读”防止后续新的写入污染 binlog 的恢复位点。一定要提“恢复到临时实例而不是直接在生产库操作”先验证数据完整性再导入生产。一定要提“恢复完成后验证数据的行数和关键业务指标”不能恢复到一半看没报错就认为完了。如果能再补充一句“如果表被 DROP还需要注意表结构是否保留比如从全备中单独恢复表结构”就更能体现细节。这类题的核心在于展示你有条不紊的故障应对能力而不是背一条命令。5.2 RPO 和 RTO两个经常被忽略的基础概念备份恢复板块里有两个概念笔试很容易出RPORecovery Point Objective恢复点目标和 RTORecovery Time Objective恢复时间目标。这两个概念很多同学在简历上写过但做题时经常搞混。RPO 指的是“数据最多丢多少”衡量的是数据丢失的容忍度。RPO 0 代表不允许丢任何数据必须做实时同步。RTO 指的是“恢复要多快”衡量的是业务中断的容忍度。RTO 越短代表业务中断时间要求越严。笔试经常会用业务化的语言来描述比如“在线支付系统的数据库不允许丢失任何一笔交易记录”这可翻译成 RPO ≈ 0“核心交易库要求 30 分钟内恢复可用”这描述的就是 RTO ≤ 30 分钟。这两个概念有什么用它们可以帮你反推备份方案。RPO 要求高就必须让 binlog 实时同步到异地或者用半同步复制RTO 要求高就得准备预热的备库或者完善的自动化切换工具而不能只靠从磁带恢复。答备份类题目时先用 RPO/RTO 把目标定义清楚再给方案会显得非常专业。5.3 主从复制与高可用方案原理比工具更重要高可用这块笔试卷的考察重点一般不是“你会不会搭 MHA”而是“你有没有理解主从复制的原理”。因为具体的工具会过时但核心原理是稳定的。MySQL 主从复制的基本流程要能说清楚主库的变更写入 binlog。备库的 IO 线程去主库拉取 binlog写入中继日志relay log。备库的 SQL 线程读取 relay log 并执行把变更应用到备库。复制相关的题目有两个非常经典的坑一个是“主从延迟”。备库回放 binlog 的速度跟不上主库写入速度导致备库数据落后。笔试如果问“主从延迟怎么解决”可以答优先检查备库磁盘 IO 是否瓶颈、是否单线程回放导致速度上不去5.6 之后可以并行复制、大事务是否拖慢回放进度必要时考虑读写分离把实时性要求高的读流量打到主库。另一个是“半同步复制与异步复制的取舍”。异步复制下主库提交事务不等待备库确认性能好但主库宕机可能丢数据半同步复制要求至少一个备库收到 binlog 并写入 relay log 后才返回提交成功RPO 更可控但性能损耗更大。笔试的时候如果能主动把“业务允许丢多少数据”和“主库能承受多大的性能损耗”这两个维度结合回答会显得很有高度。工具层面的 MHA、Orchestrator 可以作为选学内容提一嘴2018 年 MHA 还是很主流的但如果考生能说出“它是基于主从复制做故障转移本质是脚本化操作”已经比大多数人强了。6. 从一份笔试卷反推完整备考地图6.1 知识点优先级别把时间浪费在低频考点上校招备考时间有限不可能面面俱到。根据这份试卷的考察倾向我建议按优先级去投入优先级知识点建议投入第一梯队SQL 基础、索引原理、执行计划、事务隔离级别必须拿到高分这是笔试的基本盘第二梯队锁机制、死锁分析、备份恢复、主从复制区分度所在决定能不能进面试第三梯队参数调优、内核原理、分布式数据库、NoSQL有能力再深入通常占分不多第一梯队为什么必须是 SQL 和索引因为这是几乎所有数据库相关岗位的共同要求平台、业务、数据库种类都可能换但索引和事务的原理是不变的。第二梯队是 DBA 岗位的区分项开发岗不太会考主从复制和备份恢复所以这套题能筛出真正想做数据库管理的人。第三梯队不用花太多时间但如果你已经在第二梯队很扎实了适当看一些存储引擎源码分析或者分布式事务的内容在面试环节会是很好的亮点。6.2 实操练习路径本地搭一套环境自己折腾一遍笔试准备不能只看题最好把动手验证的习惯养成。准备校招期间我比较推荐做一个最小化实验环境一台普通电脑装一个 MySQL 5.7或者直接装 MySQL 8.0把下面这几个实验过一遍创建一张十万行的测试表分别在有索引和没索引的情况下执行同样的 WHERE 查询观察执行时间和 explain 输出差异。用两个终端模拟两个事务分别设置不同隔离级别观察隔离级别对读一致性的影响。手动执行UPDATE和SELECT ... FOR UPDATE制造一个死锁然后查SHOW ENGINE INNODB STATUS看死锁日志长什么样。开启slow_query_log故意写一条不带索引的查询看慢查询日志是否记录。做一次全量备份然后用 binlog 恢复到误删前时间点整个过程走一遍。这个过程能帮你把纸面知识变成肌肉记忆。特别是备份恢复如果不亲手做一次考场上遇到“误删恢复”的题只能靠想象很难答出细节。而只要你做过一次哪怕只恢复了一百行数据那道题你也能给出特别具体的步骤。6.3 笔试之外的隐性加分项怎么在面试时接住追问笔试过了还有面试面试官很多时候会在简历里找“亮点”。我建议在准备笔试的同时有意识地积累几个可以讲的经历。故障复盘不管是在实习还是自己的实验环境里遇到的任何数据库问题只要你能讲清楚现象、排查过程、根因、解决方案这就是一个好素材。哪怕是一次本地环境死锁只要复盘逻辑完整也很有说服力。工具使用percona-toolkit里的pt-query-digest、pt-online-schema-change如果你用过其中任意一个并能解释“它在线改表是怎么减少锁阻塞的”很容易打动面试官。版本特性关注MySQL 8.0 的窗口函数、CTE、降序索引、不可见索引等新特性笔试未必考但如果面试时能主动提出来并结合自己实验环境里的验证结果会让人觉得你有持续学习的习惯。这些内容不是短期能突击出来的但如果你现在离校招还有一段时间完全可以按这个方向积累。说实话我自己带过的实习生里最后拿到数据库管理工程师 offer 的往往不是最会背题目的人而是能在一两个点上讲出自己真实思考和验证的人。最后再分享一个我做错题笔记的小习惯。不要在纸上抄概念而是用“场景 → 原理 → 解决路径”三段式来记录。比如遇到一道死锁题我会写场景是两条 UPDATE 顺序不一致并发执行原理是 InnoDB 的行锁和等待环解决路径是统一事务内语句顺序、缩小事务跨度、必要时调整隔离级别。每道错题都按这个模板过一遍比单纯背概念高效得多。这份 2018 年笔试卷真正有价值的不是那几十分而是它帮你把“数据库管理工程师”这个岗位的轮廓描清楚了照着这个轮廓去补知识方向基本不会跑偏。
每年校招季我都会接触不少准备数据库方向笔试的同学看到最多的状态就是简历上写着“熟悉 MySQL”“了解索引优化”一碰到数据库管理工程师的笔试卷却在索引、事务、锁、备份恢复这些题目上翻车。网易这套 2018 校园招聘数据库管理工程师笔试卷出的题其实很有代表性它不一定考你背了多少概念而是考你有没有一个 DBA 的脑子数据出问题的时候你能不能快速定位、能不能给出可落地的恢复方案、能不能看懂一条 SQL 为什么会慢。这篇文章我不打算逐题报答案而是把这份试卷背后真正想筛的能力拆开配合典型题目场景和实操思路给准备走数据库管理方向的同学一份有参考价值的备考地图。1. 一份数据库管理工程师笔试卷到底在筛什么人1.1 写 SQL 的人和管理数据库的人完全是两种物种先想清楚一个前提数据库管理工程师不是让你来写业务 SQL 的。业务开发也会写 SQL但开发关心的是“这条查询结果对不对”DBA 关心的是“这条查询在生产环境会不会把库拖垮”。这两个视角完全不同笔试卷出题的时候也会刻意区分。比如同样面对一张订单表开发可能会写SELECT * FROM orders WHERE user_id 123能跑出结果就完事。但 DBA 看到这条语句脑子里会立刻弹出几个问题user_id 上有没有索引type 是不是 ALLrows 扫描了多少行Extra 里有没有 Using filesort如果这张表有几百万行这条语句会不会把 buffer pool 打穿有没有可能用覆盖索引减少回表所以你会发现校招笔试卷里很多题目表面上是考 SQL 语法实际考的是你有没有这种“性能敏感”和“故障敏感”的意识。你不需要有几年生产经验才能答题但你需要知道一个 DBA 看到问题时的思考路径是什么。1.2 从考点分布反推岗位能力模型虽然这份试卷具体题目每年的版本会有调整但知识板块的分布是有规律的。我根据带过的校招生和这些年看到的真题大致整理出下面这张能力地图知识板块考察目的典型题型SQL 基础与数据模型基本功是否扎实手写 SQL、范式判断、表设计索引与查询优化有没有性能意识复合索引选择、执行计划分析事务与锁机制并发控制的理解深度隔离级别、死锁场景分析备份恢复数据安全意识误删数据恢复方案设计高可用与架构视野是否局限在单机主从复制、容灾方案操作系统与网络基础排障能力下限端口、进程、磁盘 IO 相关题这里面有个容易被忽略的点数据库管理工程师的笔试卷不只是考数据库本身。操作系统、网络、存储这些周边知识也会占一定比例。原因很简单生产环境里数据库出了问题排查链路往往是从操作系统开始的。比如磁盘满了导致 MySQL 只读、网络抖动导致主从延迟、内存不足触发 OOM 导致实例重启。笔试考这些不是为了难为你而是为了确认你有没有能力在“数据库之外”找原因。1.3 2018 年这个时间点的特殊技术背景为什么要单独说年份因为校招笔试卷的考点其实紧跟当时的技术潮流。2018 年这个时间点有几个特点MySQL 5.7 是主流生产版本8.0 刚发布还没大规模铺开所以试卷里大量题目围绕 5.7 的行为展开比如半同步复制、GROUP BY 的排序逻辑、JSON 类型的支持。云数据库 RDS 开始普及但很多互联网公司核心库还是自建机房物理机所以传统 DBA 的硬核技能——mysqldump、xtrabackup、binlog 恢复、主从切换——依然是笔试重点。分库分表和分布式数据库概念开始热门但实际落地方案还不像今天这么成熟所以试卷里更多是考“水平拆分和垂直拆分的取舍”这类思维题很少考具体中间件操作。理解这个背景有什么用它能帮你判断笔试着重复习的重点应该放在“单机数据库的原理和运维”而不是上来就研究分布式数据库。很多同学看了一堆 TiDB、OceanBase 的资料结果基础题反而丢分这个方向就偏了。2. 索引与执行计划为什么这部分永远是大头2.1 最左前缀原则一道送分题怎么变成送命题索引类题目几乎是数据库笔试试卷里雷打不动的第一大户。其中最高频的考点就是复合索引的最左前缀原则。很多同学觉得这个简单但实际做题时换一个问法就懵。举一个典型题例表上有复合索引(a, b, c)下面几个查询哪些能用到索引WHERE a 1 AND b 2 AND c 3——全命中最理想。WHERE b 2 AND c 3——用不到因为没有从最左列开始。WHERE a 1 AND c 3——只能用a这一列c没法用索引过滤。WHERE a IN (1, 2) AND b 10 AND c 3——能用a和b的范围条件但c还是会失效。第 4 个例子是最容易答错的。原因是 B 树索引的匹配顺序是有方向的范围查询之后后续列无法继续用于精确定位。b 10一旦成为范围条件c就失去了参与索引匹配的机会。这就是很多人背了“最左前缀”四个字却没法解释“为什么会这样”的地方。另外一个容易被忽略的考点是排序。复合索引(a, b)不仅能加速WHERE a ?的查询还能让ORDER BY a, b直接走索引避免 filesort。笔试卷经常会问“下面这条语句能否避免 Using filesort”你只要记住索引列的顺序和排序方向一致才行ORDER BY a DESC, b ASC这种混着来的情况优化器往往做不到完美利用索引。2.2 执行计划的关键指标别把 explain 的结果当摆设如果说索引概念题是第一层那执行计划分析就是第二层。笔试不会让你真跑一条 SQL但它会给你一条 SQL 外加一个 explain 输出让你判断问题出在哪。这种题核心看四个字段type访问类型从好到差大致是const→eq_ref→ref→range→index→ALL。如果看到ALL意味着全表扫描这类 SQL 在生产环境基本会被 DBA 重点盯上。key实际用到的索引是哪个。如果为NULL说明没用到索引。rows预估扫描行数。这个数字越接近表的总行数问题越严重。Extra出现Using filesort或Using temporary是危险信号意味着查询需要额外的排序或临时表性能很难好。我见过最典型的题目是给出SELECT * FROM user WHERE age 20 ORDER BY create_time以及一个显示Using filesort的 explain 结果问怎么优化。这里有两个维度可以考虑如果age区分度不高加索引未必有显著收益但如果查询本身低频可以先建立(age, create_time)的复合索引让过滤和排序都能走索引。如果查询高频还可以考虑在create_time上单独建索引先排好序再回表过滤也行具体看统计信息。笔试面试里我一般建议你按这个路径答先做数据量级和业务频率的判断再给索引方案最后补充一句“上线前要在测试环境用真实数据量验证”。这样答出来比一上来就丢一个“加索引”的结论要专业得多。2.3 覆盖索引和索引下推能拉开差距的细节如果试卷有拔高题往往会从覆盖索引和索引下推这两个点出。覆盖索引意思是查询的所有列都在索引里不需要回表。举个例子表上有索引(user_id, status)查询SELECT status FROM order WHERE user_id 123因为user_id和status都在这颗索引树上直接遍历索引就能拿到结果省掉了一次主键回表。笔试里问“这条 SQL 为什么快”往往就是覆盖索引的功劳。索引下推Index Condition PushdownICP是 MySQL 5.6 引入的优化很多人没听说过。它的逻辑是在没有 ICP 之前存储引擎从索引中取出记录后要回表拿到完整行再由 Server 层判断其他条件有了 ICP可以在存储引擎层先把一部分条件过滤掉减少回表次数。举个经典例子复合索引(zipcode, lastname)查询WHERE zipcode 100000 AND lastname LIKE %张%。lastname LIKE %张%无法用索引匹配但 ICP 可以在读取索引记录时就用 LIKE 条件过滤掉大量无效数据再回表。笔试如果问你“ICP 有什么好处”核心答案就是减少回表次数降低 IO。能把这个细节写出来基本就能在众多候选人里拉开差距。3. 事务隔离级别与锁机制这类题怎么答才不丢分3.1 隔离级别背得下来但题还是不会做事务隔离级别这块面试笔试几乎是必考。但我发现一个普遍问题很多同学四句话背得滚瓜烂熟——读未提交有脏读读已提交解决脏读但会不可重复读可重复读解决不可重复读但可能幻读串行化最安全但性能差——可真给一个场景题就不知道怎么用了。原因在于没有理解每个隔离级别是“在性能和一致性之间做了哪种取舍”。更关键的是很多同学不知道 MySQL 的默认隔离级别是可重复读Repeatable Read而 Oracle、PostgreSQL 默认是读已提交Read Committed。这个差异在笔试里经常出现而且会直接影响后续锁机制和 MVCC 的答案。举个典型场景题事务 A 先读取了一行balance 100事务 B 修改这行变成 200并提交。请问在 RR 和 RC 下事务 A 再次读取这行分别看到什么RR 下因为快照读机制A 看到还是 100RC 下因为每次读都拿最新已提交版本A 会看到 200。这种题不需要背概念理解 MVCC 的多版本链就能答对。MVCC 是 MySQL InnoDB 实现隔离级别的核心机制笔试高频考点。它维护了一条版本链每行记录有多版本数据read view决定了事务能看到哪个版本。RR 下read view在第一次查询时生成整个事务复用RC 下每次查询都重新生成。所以 RR 下同样的查询得到一致的结果这就是快照读层面的“一致性读”。3.2 行锁、间隙锁、next-key lock 的典型场景MVCC 解决了快照读的隔离问题但更新操作是“当前读”需要真正的锁。这就引出了行锁、间隙锁、next-key lock 这些考点。很多校招生对锁的理解停留在“读锁和写锁”这个层面一旦笔试问到 InnoDB 的具体锁类别就乱了。这里需要清楚几个层次共享锁S 锁和排他锁X 锁最基础的锁类型一行记录可以被多个事务加 S 锁但 X 锁只能被一个事务持有。记录锁Record Lock锁住的是索引记录本身注意 InnoDB 是通过索引来锁行的不是直接锁物理行。间隙锁Gap Lock锁住索引记录之间的间隙防止其他事务在这个间隙插入新的记录用来解决幻读。Next-key Lock记录锁 间隙锁的组合锁住的范围是一个左开右闭区间(前一条记录, 当前记录]。典型笔试场景在 RR 隔离级别下数据库有 id 为 1、5、10 三行事务 A 执行SELECT * FROM t WHERE id 5 FOR UPDATE。这个语句会锁住id 5的记录行吗还会不会锁住(5, 10]和(10, ∞)的间隙答案是它会锁住 id10 这一行同时因为 RR 下默认用 next-key lock间隙(5, 10)和(10, 正无穷)也会被锁其他事务想插入 id8 或 id100 都会被阻塞。很多人不理解为什么“查不到的行”还要加锁。这就是 RR 隔离级别为了防幻读付出的代价。如果笔试题目问“数据库默认隔离级别下间隙锁会带来什么副作用”你可以答降低并发插入能力容易引发死锁这也是很多互联网公司把隔离级别从 RR 改成 RC 的原因之一因为 RC 下只存在记录锁间隙锁被禁用了死锁概率会明显下降。3.3 死锁分析题怎么把排查思路写到卷子上死锁是 DBA 工作中必须面对的问题笔试卷尽量不会出太复杂但一定会出一个典型场景两个事务各自持有一个锁又同时等待对方持有的锁。最常见的就是两条 UPDATE 语句顺序相反。事务 A 先更新 id1 再更新 id2事务 B 先更新 id2 再更新 id1。当两个事务并发执行时A 持有 id1 的锁在等 id2B 持有 id2 的锁在等 id1互相不肯放手InnoDB 检测到死锁后会选择回滚一个代价较小的事务。笔试遇到这种题答题的关键不是把死锁定义默写一遍而是给出一个完整的分析链条两个事务各自持有什么锁、正在等什么锁画一个等待环出来。如何从SHOW ENGINE INNODB STATUS的日志里发现死锁信息看LATEST DETECTED DEADLOCK部分。往业务层面怎么修统一 UPDATE 语句里条件的顺序保证所有事务按相同顺序访问行或者缩短事务持续时间减少锁持有的窗口。如果业务确实没法调整顺序可以在高峰期前通过SELECT ... FOR UPDATE预锁定目标行或者考虑降低隔离级别到 RC减少间隙锁带来的死锁可能性。这套答法能体现出你不是在背概念而是真的想过“如果我来值班我会怎么处理”。还有一个小细节在描述死锁时一定要提到 InnoDB 会通过检测机制而不是超时机制来处理大部分死锁死锁检测默认开启并且会把回滚代价较小的事务选为 victim。这个细节能加分。4. SQL 优化与慢查询排查笔试题背后的运维思维4.1 一道 SQL 优化题考察的其实是排查顺序数据库管理工程师岗位笔试基本不会绕过 SQL 优化这块。但这类题目并不单纯考“你会不会写高效 SQL”而是考你看到一个慢 SQL 之后脑子里有没有一条标准的排查链路。我建议所有准备笔试的同学把一个思路印在脑海里慢 SQL 出现后第一步永远是确认问题现象而不是急着改 SQL。比如这条 SQL 是偶发慢还是持续慢慢的时候系统整体负载如何有没有其他大查询并行表数据量最近有没有突增执行计划有没有变化是不是统计信息不准确导致走了错误索引很多校招生一看到慢 SQL 就回答“加索引”这是最典型的扣分项。真实生产环境里一条 SQL 变慢的原因可能很多统计信息过期导致执行计划偏离、锁竞争导致阻塞、磁盘 IO 抖动、查询缓存失效、或者网络延迟。不加判断直接加索引往往解决不了实际问题。如果笔试卷给的具体场景是“订单表 order 有 500 万行查询SELECT * FROM order WHERE user_id 123 ORDER BY create_time DESC LIMIT 20很慢怎么优化”我会这么拆解先看user_id是否有索引。如果没有全表扫描是必然的首选是加(user_id, create_time)复合索引让过滤和排序同时走索引。如果已经有索引但还慢看查询是否用到了回表。SELECT *意味着查询所有列即使索引命中也得回表拿数据。考虑改成覆盖索引只返回必要字段减少回表次数。如果业务允许考虑把LIMIT 20变成一个基于游标的翻页方式避免深分页问题比如用WHERE create_time 上次查询的最后一条时间来替代OFFSET。这种回答顺序展示的是“定位问题 → 分析原因 → 给方案 → 预估效果”的完整闭环比单纯丢一个方案扎实很多。4.2 慢查询日志与工具链笔试怎么考慢查询日志是 DBA 定位慢 SQL 的第一手数据。笔试卷可能不会直接考命令参数但会给你一个场景某天业务方反馈线上接口变慢你要怎么找出慢 SQL。我的建议是把以下概念理清slow_query_log开启开关long_query_time阈值。生产环境一般设 1 秒如果实例压力大可以调到 2 秒或 5 秒避免日志刷太多。log_queries_not_using_indexes可以记录没走索引的查询这在笔试里可以作为一个补充点提出来说明你有“提前发现隐患”的意识。日志拿到后可以用mysqldumpslow或pt-query-digest做聚合分析按执行时间、扫描行数排序筛选出真正需要处理的头部 SQL。笔试考这个点的意图是看你有没有“从海量日志里找到关键问题”的思路。回答时不需要很细节地背出每个参数但一定要能说清楚“谁的日志、怎么开启、达到什么阈值、如何分析”这样逻辑就完整了。4.3 分库分表概念题背后的架构思维2018 年前后的笔试分库分表开始频繁出现。这类题目通常是概念题加一点设计题。比如单表数据量到了几千万写性能下降要不要分库分表怎么分这里有一个很关键的判断分库分表是最后手段不是第一选择。笔试卷里如果考这个正确答案的第一步往往是先排除其他可能性归档历史数据、优化索引、升级硬件、读写分离。很多同学上来就说“按 user_id 分 64 张表”忽略了业务场景反而暴露了“没有真实运维经验”的问题。如果确实要分需要说清楚两个方向水平拆分同一张表的数据按照某个分片键拆到多张表。比如订单表按order_id哈希分片每个分片存不同范围的数据。优点是水平扩展能力强缺点是跨分片的 JOIN、聚合、事务会变得复杂。垂直拆分把不同的业务列拆到不同的表或库里。比如把热点字段和非热点字段分开。优点是单表变瘦、缓存命中率提高缺点是拆分后查询逻辑变复杂。答这种题的时候如果能顺带提一句“分片键的选择特别重要要尽量让查询带上分片键避免跨分片扫描”会显得你有落地思考。因为真实场景里分片键选错会导致大量广播查询性能比不分片还差。5. 备份恢复与高可用笔试里偏“架构”的题目怎么切入5.1 从“误删数据”场景看备份恢复能力数据库管理工程师和开发工程师最大的区别就是你对“数据没了”这件事有多敏感。笔试卷里大概率会出一道备份恢复的题最常见的场景是某天凌晨三点一个同事执行了一条DELETE或者DROP TABLE误删了核心表数据你作为 DBA怎么处理这道题没有标准答案但有一条比较完整的思路线先冷静别让问题扩大。如果误删是刚发生的立刻检查 binlog 是否开启。MySQL 生产环境一般都会开启log_bin如果开启了恢复就有戏。确认全量备份的情况。上次全备是什么时候用mysqldump还是xtrabackup如果全备存在可以起一个临时实例把全备恢复到误删前一秒的状态。用 binlog 做增量追加。全备恢复到某个时间点之后把误删时刻之前的 binlog 重放到临时实例利用mysqlbinlog --stop-datetime或者--stop-position精确截断。最后再把临时实例里的这部分数据导回生产库。这个流程里有几个笔试高频坑点一定要提“先停止业务写入或者把表置为只读”防止后续新的写入污染 binlog 的恢复位点。一定要提“恢复到临时实例而不是直接在生产库操作”先验证数据完整性再导入生产。一定要提“恢复完成后验证数据的行数和关键业务指标”不能恢复到一半看没报错就认为完了。如果能再补充一句“如果表被 DROP还需要注意表结构是否保留比如从全备中单独恢复表结构”就更能体现细节。这类题的核心在于展示你有条不紊的故障应对能力而不是背一条命令。5.2 RPO 和 RTO两个经常被忽略的基础概念备份恢复板块里有两个概念笔试很容易出RPORecovery Point Objective恢复点目标和 RTORecovery Time Objective恢复时间目标。这两个概念很多同学在简历上写过但做题时经常搞混。RPO 指的是“数据最多丢多少”衡量的是数据丢失的容忍度。RPO 0 代表不允许丢任何数据必须做实时同步。RTO 指的是“恢复要多快”衡量的是业务中断的容忍度。RTO 越短代表业务中断时间要求越严。笔试经常会用业务化的语言来描述比如“在线支付系统的数据库不允许丢失任何一笔交易记录”这可翻译成 RPO ≈ 0“核心交易库要求 30 分钟内恢复可用”这描述的就是 RTO ≤ 30 分钟。这两个概念有什么用它们可以帮你反推备份方案。RPO 要求高就必须让 binlog 实时同步到异地或者用半同步复制RTO 要求高就得准备预热的备库或者完善的自动化切换工具而不能只靠从磁带恢复。答备份类题目时先用 RPO/RTO 把目标定义清楚再给方案会显得非常专业。5.3 主从复制与高可用方案原理比工具更重要高可用这块笔试卷的考察重点一般不是“你会不会搭 MHA”而是“你有没有理解主从复制的原理”。因为具体的工具会过时但核心原理是稳定的。MySQL 主从复制的基本流程要能说清楚主库的变更写入 binlog。备库的 IO 线程去主库拉取 binlog写入中继日志relay log。备库的 SQL 线程读取 relay log 并执行把变更应用到备库。复制相关的题目有两个非常经典的坑一个是“主从延迟”。备库回放 binlog 的速度跟不上主库写入速度导致备库数据落后。笔试如果问“主从延迟怎么解决”可以答优先检查备库磁盘 IO 是否瓶颈、是否单线程回放导致速度上不去5.6 之后可以并行复制、大事务是否拖慢回放进度必要时考虑读写分离把实时性要求高的读流量打到主库。另一个是“半同步复制与异步复制的取舍”。异步复制下主库提交事务不等待备库确认性能好但主库宕机可能丢数据半同步复制要求至少一个备库收到 binlog 并写入 relay log 后才返回提交成功RPO 更可控但性能损耗更大。笔试的时候如果能主动把“业务允许丢多少数据”和“主库能承受多大的性能损耗”这两个维度结合回答会显得很有高度。工具层面的 MHA、Orchestrator 可以作为选学内容提一嘴2018 年 MHA 还是很主流的但如果考生能说出“它是基于主从复制做故障转移本质是脚本化操作”已经比大多数人强了。6. 从一份笔试卷反推完整备考地图6.1 知识点优先级别把时间浪费在低频考点上校招备考时间有限不可能面面俱到。根据这份试卷的考察倾向我建议按优先级去投入优先级知识点建议投入第一梯队SQL 基础、索引原理、执行计划、事务隔离级别必须拿到高分这是笔试的基本盘第二梯队锁机制、死锁分析、备份恢复、主从复制区分度所在决定能不能进面试第三梯队参数调优、内核原理、分布式数据库、NoSQL有能力再深入通常占分不多第一梯队为什么必须是 SQL 和索引因为这是几乎所有数据库相关岗位的共同要求平台、业务、数据库种类都可能换但索引和事务的原理是不变的。第二梯队是 DBA 岗位的区分项开发岗不太会考主从复制和备份恢复所以这套题能筛出真正想做数据库管理的人。第三梯队不用花太多时间但如果你已经在第二梯队很扎实了适当看一些存储引擎源码分析或者分布式事务的内容在面试环节会是很好的亮点。6.2 实操练习路径本地搭一套环境自己折腾一遍笔试准备不能只看题最好把动手验证的习惯养成。准备校招期间我比较推荐做一个最小化实验环境一台普通电脑装一个 MySQL 5.7或者直接装 MySQL 8.0把下面这几个实验过一遍创建一张十万行的测试表分别在有索引和没索引的情况下执行同样的 WHERE 查询观察执行时间和 explain 输出差异。用两个终端模拟两个事务分别设置不同隔离级别观察隔离级别对读一致性的影响。手动执行UPDATE和SELECT ... FOR UPDATE制造一个死锁然后查SHOW ENGINE INNODB STATUS看死锁日志长什么样。开启slow_query_log故意写一条不带索引的查询看慢查询日志是否记录。做一次全量备份然后用 binlog 恢复到误删前时间点整个过程走一遍。这个过程能帮你把纸面知识变成肌肉记忆。特别是备份恢复如果不亲手做一次考场上遇到“误删恢复”的题只能靠想象很难答出细节。而只要你做过一次哪怕只恢复了一百行数据那道题你也能给出特别具体的步骤。6.3 笔试之外的隐性加分项怎么在面试时接住追问笔试过了还有面试面试官很多时候会在简历里找“亮点”。我建议在准备笔试的同时有意识地积累几个可以讲的经历。故障复盘不管是在实习还是自己的实验环境里遇到的任何数据库问题只要你能讲清楚现象、排查过程、根因、解决方案这就是一个好素材。哪怕是一次本地环境死锁只要复盘逻辑完整也很有说服力。工具使用percona-toolkit里的pt-query-digest、pt-online-schema-change如果你用过其中任意一个并能解释“它在线改表是怎么减少锁阻塞的”很容易打动面试官。版本特性关注MySQL 8.0 的窗口函数、CTE、降序索引、不可见索引等新特性笔试未必考但如果面试时能主动提出来并结合自己实验环境里的验证结果会让人觉得你有持续学习的习惯。这些内容不是短期能突击出来的但如果你现在离校招还有一段时间完全可以按这个方向积累。说实话我自己带过的实习生里最后拿到数据库管理工程师 offer 的往往不是最会背题目的人而是能在一两个点上讲出自己真实思考和验证的人。最后再分享一个我做错题笔记的小习惯。不要在纸上抄概念而是用“场景 → 原理 → 解决路径”三段式来记录。比如遇到一道死锁题我会写场景是两条 UPDATE 顺序不一致并发执行原理是 InnoDB 的行锁和等待环解决路径是统一事务内语句顺序、缩小事务跨度、必要时调整隔离级别。每道错题都按这个模板过一遍比单纯背概念高效得多。这份 2018 年笔试卷真正有价值的不是那几十分而是它帮你把“数据库管理工程师”这个岗位的轮廓描清楚了照着这个轮廓去补知识方向基本不会跑偏。
