前阵子好几个学弟学妹来问我说报考了网易杭研的数据库管理工程师岗位但笔试到底考什么、怎么准备网上能找到的信息特别零散不是培训机构广告就是一篇篇零碎的面试题整理看着毫无体系。我这些年也算是在数据这条线上摸爬滚打过来的做过线上业务的DBA也当过校招笔试的阅卷人数据库管理工程师这套笔试的考察套路其实是有章可循的。趁着这个机会我把这类笔试的准备思路完整梳理一遍。这篇内容不只对应网易杭研2023校招的数据库管理工程师岗位只要是互联网中大厂的DBA方向笔试基本都可以按这个逻辑去准备。文章会从岗位能力模型反推考察逻辑再到高频考点、SQL和方案设计题的解题套路最后聊聊应试时的时间分配和避坑经验适合正在准备校招笔试的应届生也适合想往数据库方向转岗的同学参考。1. 笔试到底在考什么从岗位职责反推考察逻辑1.1 数据库管理工程师的能力模型拆解先说结论数据库管理工程师这个岗位笔试考察的核心不是你会多少种数据库产品而是你有没有建立一套完整的数据库工程思维。很多同学以为DBA就是会写SQL、会装MySQL实际上校招笔试的出发点完全不同——面试官想通过试卷判断你有没有能力在真实生产环境里把数据库管好、用好、救回来。从岗位JD反推数据库管理工程师的日常工作可以拆成四块一是数据库的架构设计与选型比如业务读多写少该上什么架构数据量涨到百万级要不要分库分表二是日常运维保障包括监控告警、备份恢复、参数调优、版本升级三是SQL与性能优化比如慢查询分析、索引设计、执行计划解读四是异常应急处理比如主从延迟、死锁、磁盘满了怎么办。对应到笔试这四块能力会转化为四个方向的题目基础原理题考察你对数据库内核机制的理解程度、SQL实操题考察你写SQL和优化SQL的能力、方案设计题考察你在真实业务场景下的架构与运维设计能力、以及一部分系统综合题考察操作系统、网络等基础设施知识的扎实程度。这里提醒准备的同学注意一个误区不要以为笔试只是走个过场机试过了还有面试。笔试成绩在后续流程里很重要尤其对于DBA这类技术岗位笔试分数直接决定了面试官对你的第一印象甚至在排序的时候会作为重要参考。所以笔试不是随便刷刷题就行的事。1.2 笔试与面试的分工不同别用面经思路准备笔试我见过不少同学拿着面试题库去准备笔试这就搞错方向了。面试可以靠聊——面试官会引导你你说出大概思路他就能判断你的水平。但笔试完全是写没有提示、没有引导你在纸上写出来的每一个结论、每一段SQL、每一个参数都被视作你真实的水平。所以笔试考察的是更加细节、更加量化的知识。举个例子。面试可以问MySQL的索引底层结构是什么你回答B树就过关了但笔试会把题目出成为什么InnoDB选择B树而不是B树或哈希索引这就是两种考察深度。再比如索引失效的题目面试会问你遇到过哪些索引失效的场景你可以举例但笔试会直接给你两三条SQL让你判断哪条能走索引、哪条不能走还要解释原因。这就逼着你把底层原理真正吃透不能停留在背诵结论的层面。另外笔试还有一个隐性目的考察你的工程习惯。大厂的校招笔试通常会有一定量的多选题和场景题题目本身不难但会在选项里埋坑用来筛选掉基础不扎实的人。还有一类题是给你一段线上业务的背景描述让你去设计解决方案这种题没有唯一答案考察的是你的思考框架是否完整、边界条件是否考虑周全。2. 基础原理储备高频考点与核心理解方式2.1 索引部分不只是背B树而是理解设计动机索引相关的内容在数据库管理工程师笔试里几乎是必考的而且分值占比不低。高频考点集中在几个方面B树的结构特点与优势、聚簇索引与非聚簇索引的区别、联合索引的最左前缀原则、索引失效的常见场景、覆盖索引与回表的理解。我建议不要死记硬背结论而是从设计动机去理解。比如B树为什么比B树更适合做数据库索引关键在于两点一是B树的数据都存放在叶子节点并且叶子节点之间用链表连接这让范围查询变得非常高效——你只需要找到起点然后沿着链表顺序往后读就行而B树的节点内部会存储数据导致中序遍历需要在不同层级的节点之间来回跳范围查询性能差很多。二是B树的非叶子节点不存数据只存索引键所以同样的页大小可以容纳更多的索引项树的高度更低磁盘IO次数更少。笔试里还经常出现一类题给你一条SQL判断是否走索引以及为什么。这类题就需要把索引失效的场景全部吃透。常见的索引失效场景有这么几类对索引列进行了函数运算或表达式计算比如WHERE DATE(create_time) 2023-01-01隐式类型转换导致索引失效比如某列是varchar类型但查询条件用了数字LIKE前缀模糊查询比如LIKE %关键词联合索引不满足最左前缀原则使用OR连接非索引列。要特别提醒的是判断索引是否失效不是只看规则还要结合数据量和优化器的选择。有时候即使条件满足走索引的条件但如果优化器估算全表扫描成本更低它也会放弃索引。笔试题如果出到这种深度通常会在题目里给出表数据量的描述你要能根据数据量级做合理判断。2.2 事务与锁隔离级别、MVCC和死锁是三类核心题事务相关知识点在笔试中占比也很高。核心考点包括ACID特性、隔离级别的定义与问题对应关系、MVCC的实现机制、锁的类型与兼容矩阵、死锁的产生条件与排查思路。先说隔离级别。四档隔离级别——读未提交、读已提交、可重复读、串行化——要背清楚但更要紧的是理解每一档解决了什么问题、又会引入什么问题。很多人背结论背得很熟读已提交解决脏读可重复读解决不可重复读串行化解决幻读。但如果笔试题目换个问法比如可重复读隔离级别下InnoDB如何解决幻读问题很多人就答不上来了。这里的关键是搞清楚加锁方式上的差异可重复读下InnoDB通过间隙锁gap lock和临键锁next-key lock来锁定范围阻止其他事务在该范围内插入新记录从而解决幻读。MVCC这块需要理解三个核心概念隐藏字段DB_TRX_ID、DB_ROLL_PTR、undo log版本链、ReadView。笔试常考的问题是在不同隔离级别下ReadView的生成时机有什么区别。简单说读已提交每次SELECT都会生成新的ReadView因此能读到其他事务已提交的最新数据可重复读只在第一次SELECT时生成ReadView后续复用同一个快照因此整个事务期间看到的数据是一致的。这个区别是理解两种隔离级别行为差异的核心。死锁相关的题目也经常出现。笔试一般不会让你去现场调试死锁而是给你一个场景判断会不会死锁、为什么死锁以及如何避免。这类题考察的是对锁兼容矩阵的理解和加锁顺序的分析。一条非常实用的经验是事务里对多个表或多个索引范围的加锁顺序要一致否则就容易出问题。2.3 日志机制binlog、redo log、undo log各有分工日志是数据库管理工程师笔试里比较有区分度的考点。很多同学对索引、事务都很熟但一聊到日志就含糊了。笔试恰恰喜欢考这些模糊地带。首先要分清三份日志各自的作用。redo log是InnoDB存储引擎层的事务日志记录的是物理页面的修改操作用于崩溃恢复保证事务的持久性undo log也是InnoDB存储引擎层的记录的是逻辑日志用于事务回滚和MVCC多版本控制binlog是MySQL Server层的二进制日志记录的是逻辑操作比如更新了某行数据为某个值用于数据复制和数据恢复。笔试常见的考法有这么几种一是问你redo log为什么需要配合binlog使用这里要引出两阶段提交prepare阶段、commit阶段二是给你一个场景比如数据库崩溃了问你哪些日志能用来恢复数据三是问主从复制依赖的是哪份日志——答案是binlog。两阶段提交这个点笔试特别喜欢考而且经常以流程图分析的形式出现。简单说要理解事务提交时InnoDB先写redo log并标记为prepare状态然后MySQL Server写binlog完了之后InnoDB再把redo log标记为commit状态。为什么需要这个两阶段因为要保证redo log和binlog两份日志的一致性。如果不用两阶段可能出现redo log写了但binlog没写的情况崩溃恢复后主库有这条数据、从库没有主从数据就不一致了。3. SQL实操题常见题型与拿分细节3.1 分组聚合与联表查询笔试SQL题的基本盘数据库管理工程师笔试里的SQL题一般是必做题而且是可以在短时间内快速拿分的部分。题型通常分几类基础增删改查、分组聚合、多表联查、子查询、窗口函数。难度一般不会超过互联网公司日常开发的实际需求但会设计一些容易踩坑的细节。比如分组聚合题经常考的一类坑是WHERE和HAVING的使用区别。简单说WHERE是在分组之前过滤行记录而HAVING是在分组之后过滤组记录。如果你的过滤条件里用了聚合函数比如查询平均分大于80分的班级那必须用HAVING因为AVG()是在分组后计算出来的WHERE根本拿不到这个值。但如果面试官换一种问法叫你写查询2023年入学且平均分大于80分的班级那就需要把时间条件放在WHERE里先过滤再把班级平均分的条件放在HAVING里过滤两个都不能少。联表查询是另一个必考重点。笔试会考察INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL JOIN的区别以及ON和WHERE条件放置位置不同带来的结果差异。这个差异说穿了还是过滤时机的问题。LEFT JOIN中如果ON条件里的过滤不匹配左表记录仍然会保留只是右表字段为NULL如果把这个条件放到WHERE里那等价于把不匹配的行过滤掉LEFT JOIN的效果变成了INNER JOIN。这个坑在笔试选择题里经常作为干扰项出现。我在阅卷的时候发现一个普遍现象很多同学在联表时会习惯性地用逗号隐式连接比如SELECT * FROM a, b WHERE a.id b.a_id。这种写法虽然能跑出来但在笔试中建议还是显式写成JOIN ... ON ...。原因是显式连接的语义更清晰阅卷人也更容易判断你的思路而且一些复杂的题目比如三表四表联查隐式连接的WHERE条件会变得非常混乱容易出错。3.2 窗口函数连续问题和TopN问题的标准解法近几年数据库管理工程师笔试中的SQL题窗口函数出现频率明显上升。如果你还只会用GROUP BY很多题写出来会非常绕甚至写不出来。窗口函数的核心价值在于它能在不合并行的前提下对每一行数据进行基于分组或全量的计算解决了分组后还要保留明细行这类问题。最常见的窗口函数题有两类。第一类是TopN问题比如查询每个部门薪资排名前3的员工。这类题的标准解法是使用ROW_NUMBER()或RANK()配合PARTITION BY。比如这样写SELECT department_id, employee_name, salary FROM ( SELECT department_id, employee_name, salary, ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rn FROM employee ) t WHERE t.rn 3;这里要注意一个细节ROW_NUMBER()、RANK()和DENSE_RANK()三个函数的差异。ROW_NUMBER()是纯粹的物理排名即使薪资相同也会分出1、2、3RANK()在遇到并列时会跳过后续的名次比如两个人并列第一下一个就是第三名DENSE_RANK()在遇到并列时不跳过名次按1、1、2这样排。笔试如果问获取每个部门薪资前三且允许并列这类需求你就需要根据题意选择合适的函数这就是刻意设计的区分点。第二类是连续问题比如查询连续登录3天以上的用户。这类题目如果用手工循环很难写标准解法是利用日期减去行号的思路。原理是如果用户连续登录那么登录日期减去一个递增的行号会得到一个不变的值一旦中断这个值就会改变。于是问题就转化为按用户和这个差值分组统计每组的天数。这类题在笔试里属于压轴SQL题但思路掌握了之后其实套路非常固定。实际写SQL时还要注意线上笔试环境一般会提供数据表样例和运行环境你可以在本地先跑通再提交。如果笔试环境不支持你反复调试那就先在草稿纸上把逻辑理清楚注意表名、字段名的大小写以及必要的分号和空格避免低级语法错误。3.3 SQL优化题从执行计划反推优化手段除了写SQL数据库管理工程师笔试还会考察SQL优化的能力。常见出题方式有两种一是给你一条慢SQL让你分析原因并给出优化方案二是给你一段执行计划的关键信息让你判断瓶颈在哪里。先说慢SQL分析。拿到一条慢SQL标准的思考顺序是先看表结构和数据量判断是否缺少索引再看WHERE条件和JOIN条件检查是否有隐式类型转换、函数运算导致索引失效然后看SELECT列的字段判断是否存在不必要的回表最后看ORDER BY和GROUP BY确认是否有额外排序。举个例子。一条常见的慢SQL是SELECT * FROM orders WHERE order_status 1 ORDER BY created_at DESC LIMIT 20;如果orders表有几百万行order_status区分度不高created_at上又没有索引这条SQL大概率会走全表扫描然后filesort排序。优化思路是什么如果业务上只关心待处理订单可以考虑在order_status和created_at上建联合索引这样既可以利用索引过滤状态又可以通过索引完成排序避免filesort。如果待处理订单本身占比很小索引效果会很明显但如果状态字段区分度很差比如90%的订单都是状态1那这个索引的意义就不大可能需要考虑其他方案比如按时间分表或使用汇总表。再补充一个笔试中的高频点执行计划里的type字段从好到差大致是system const eq_ref ref range index ALL。笔试喜欢让你判断一条SQL的执行计划是哪种类型或者从执行计划倒推查询为什么慢。这里有一个容易混淆的点range和index的区别range是索引范围扫描比如WHERE id BETWEEN 100 AND 200只扫了一部分索引index是索引全扫描比如SELECT id FROM table遍历了整个索引树。两者都是走索引但性能和定位完全不同。4. 方案设计题备份恢复、高可用与容灾设计框架4.1 备份与恢复设计用RTO和RPO指标倒推方案方案设计题是数据库管理工程师笔试的区分度所在也是后续面试的必问题型。这类题不会让你写具体的代码而是给你一个业务场景让你设计一套方案。常见的场景包括备份恢复方案设计、高可用架构设计、大表清理方案、数据迁移方案、容量规划等。先讲备份恢复。这类题的目标很明确在给定条件下设计一套能满足业务容灾需求的备份体系。做这类题有一个非常实用的入手点就是先明确两个核心指标RTO恢复时间目标和RPO恢复点目标。RTO是故障发生后业务最多能容忍多久没数据可用RPO是故障发生后最多允许丢失多少数据。举个例子。如果业务要求RTO在30分钟以内RPO在10分钟以内那每天凌晨一次全量备份肯定是不够的——最坏情况下要恢复到昨天凌晨的数据丢失一整天RPO远远超标。这时候就需要在全量备份的基础上增加定期增量备份或binlog备份把恢复窗口缩短到分钟级别。同时为了让恢复过程足够快备份文件最好是物理备份而不是逻辑备份因为物理备份的恢复速度要快得多。具体到方案可以这样写每天凌晨2点做一次全量备份同时开启binlog并保留最近7天的binlog每10分钟做一次增量备份或者使用binlog同步到异地存储恢复流程是先恢复最近的全量备份再按时间顺序重放增量备份或binlog日志最终恢复到故障前10分钟以内的状态。整个方案要说明RTO可以控制在什么水平、RPO可以控制在什么水平并且要说明如果RPO必须为零需要引入其他机制比如半同步复制或者SR同步复制技术。4.2 高可用架构设计从单点到多节点演进高可用方案设计也是笔试常客。题目场景一般会给出业务规模和发展预期让你设计主从架构或集群方案。回答这类题核心是掌握常见架构的演进路径和各自适用场景。从单体到高可用最常见的是一主一从或一主多从架构。主库负责写从库负责读通过binlog复制保持主从数据一致。面试官或者阅卷人期待你回答的不只是这个拓扑结构还包括主库故障怎么切换、从库故障怎么处理、主从延迟怎么办、脑裂怎么防止。比如主库故障需要把从库提升为新的主库这里就涉及判断主库是否真的挂了、如何避免两个库同时写入的脑裂问题。在此基础上如果业务量继续增长可能需要考虑数据库中间件来做读写分离和分库分表。笔试中常见的分层是先用Proxy做读写分离解决读扩展问题再按业务维度分库把不同业务的数据拆开或者把核心表按时间或ID范围做分表。分库分表之后还会引入新的问题比如跨库JOIN变得困难、分布式事务复杂度上升、全局唯一ID方案选择等。笔试题目如果给出这些追问你需要展示出对应的解决方案比如通过冗余字段避免跨库JOIN采用事务消息或TCC方案处理分布式事务使用雪花算法生成全局ID。高可用方面还有一个高频考点主从复制的原理。简单说主库把数据变更写入binlog从库的IO线程拉取binlog并写入本地的relay log再从库的SQL线程读取relay log并回放。笔试可能考半同步复制和异步复制的区别。异步复制下主库提交事务不等待从库确认所以主库故障时可能丢数据半同步复制要求至少一个从库收到binlog并写入relay log后才能提交所以能大幅降低数据丢失风险但会增加提交延迟。理解了这些区别才能在不同业务场景下做出合理选型。4.3 大表清理与数据迁移边界条件比方案本身更重要方案设计题经常会有一些隐蔽的边界条件阅卷人真正想看的是你有没有把这些边界条件考虑进去。以大表清理为例题目可能这样出orders表有1亿行数据需要清理一年前的历史数据怎么做常见的错误答案是直接把一年前的数据DELETE掉。这个方案在数据量少的时候没问题但上亿行的删除操作会引发几个严重问题单条DELETE会加锁事务变大后持有锁的时间很长可能拖垮线上性能大量undo log会产生磁盘空间和回滚压力都很大主从同步延迟也可能因此飙升。一个更稳妥的思路是分批量删除比如每次只删除1000条循环执行同时在业务低峰期进行。进一步如果表本身已经很大单表上亿行不管怎么删DELETE的代价都不低还容易导致表碎片化。更优雅的方式是使用分区表按时间分区清理时直接DROP掉整个分区代价极低。或者通过新建表数据重放的方式切换表在业务侧配合完成数据清理。数据迁移方案题也类似常见场景是把MySQL数据迁移到新的硬件或新的版本整个过程要保证业务不中断、数据不丢失。这里就需要按步骤设计方案先用全量工具把数据同步到新库再开启增量同步追平数据然后在业务低峰期进行切换最后通过校验工具对比两边的数据是否一致。每一步都要明确检查点和回退方案。记住一个原则方案设计题里边界条件往往比主流程更重要。5. 实战应考策略题型分布、时间分配与答题顺序5.1 合理分配时间先拿基础分再攻坚难题数据库管理工程师的笔试形式一般是限时在线作答常见时长在90到120分钟题目包含单选题、多选题、填空题、SQL编程题和方案设计题。题型分布不同作答策略也要相应调整。我个人的建议是优先保证基础题的正确率再花时间去做综合设计题。选择题和填空题虽然分值小但数量多总体占分并不低而且往往是送分题只要你基础扎实就能拿稳。SQL编程题属于中等难度建议在基础题做完之后优先处理因为SQL题只要思路对、语法对得分率很高。方案设计题放到最后这类题耗时最长而且就算时间不够只要你把框架搭出来、关键点写出来也是能拿不少分的。时间分配上假如笔试总时长120分钟可以这样安排前30到40分钟解决选择、填空和判断题中间50到60分钟写SQL题包括调试最后20到30分钟处理方案设计题就算压哨也要把核心思路和拓扑写清楚。这个节奏不是绝对的但基本逻辑是优先保住稳的分数不要在一道题上死磕。我当年见过一个反面案例有个同学在第一道多选上纠结了20多分钟结果后面的SQL题和设计题都没时间写。笔试分数不是按单题满分来排的是按整体正确率来排的为了一道题丢了一整块分数非常不划算。5.2 笔试过程中的细节陷阱不要只在SQL编辑器里栽跟头线上笔试的环境和本地IDE不完全一样这里有几个实际踩过的坑提前说一下。第一注意SQL提交格式。有些平台要求每条SQL单独提交有些平台是让你在同一个输入框里写多条SQL用分号分隔。在草稿阶段就要关注平台的说明否则一条SQL写错可能导致整段判题失败。第二注意表名与字段名的大小写。笔试平台一般不区分大小写但表名字段名尽量和题目完全一致才是稳妥的。SQL题如果跑不通浪费的调试时间相当宝贵。第三选择题里特别留意以下说法不正确的是这类否定式提问。这类题目的干扰项会把看上去正确的错误说法放在里面你需要逐一判断。建议在读题时先把不正确三个字圈出来否则很容易被带偏。第四方案设计题不要只写文字描述。如果题目没有明确限制可以用简单的ASCII箭头来画架构图比如App - Proxy - MySQL主库/从库这种表达方式在阅卷时比纯文字更清晰能帮你更快拿到采分点。5.3 一个通用的笔试答案自查清单每次交卷之前建议快速过一遍以下要点可以少犯很多低级错误SQL关键词和字段名拼写是否正确大小写是否统一。分组聚合里过滤条件是不是在HAVING里而不是误写进WHERE。JOIN类型是否选对ON条件是否完整有没有遗漏关联字段。方案设计题里是否明确写了RTO和RPO是否提到了故障切换流程。多选和判断这种带陷阱的题型有没有漏选或错选。时间计划有没有被打乱设计题是否留出了至少15分钟。最后再分享一个我自己的经验。笔试准备不能只停留在看题和背答案一定要动手写SQL、动手画方案。有些知识你看书的时候觉得懂了真让你在90分钟里默写出一份完整的SQL或者画出一套高可用方案完全不是一回事。建议至少拿出3天时间把索引、事务、日志、主从复制、备份恢复这几个核心模块的知识体系分别整理成自己的树状图再配合笔试题库做专项训练。这个过程是枯燥的但数据库管理工程师笔试从来都不是靠押题就能过的它是你整个知识体系硬实力的体现。
前阵子好几个学弟学妹来问我说报考了网易杭研的数据库管理工程师岗位但笔试到底考什么、怎么准备网上能找到的信息特别零散不是培训机构广告就是一篇篇零碎的面试题整理看着毫无体系。我这些年也算是在数据这条线上摸爬滚打过来的做过线上业务的DBA也当过校招笔试的阅卷人数据库管理工程师这套笔试的考察套路其实是有章可循的。趁着这个机会我把这类笔试的准备思路完整梳理一遍。这篇内容不只对应网易杭研2023校招的数据库管理工程师岗位只要是互联网中大厂的DBA方向笔试基本都可以按这个逻辑去准备。文章会从岗位能力模型反推考察逻辑再到高频考点、SQL和方案设计题的解题套路最后聊聊应试时的时间分配和避坑经验适合正在准备校招笔试的应届生也适合想往数据库方向转岗的同学参考。1. 笔试到底在考什么从岗位职责反推考察逻辑1.1 数据库管理工程师的能力模型拆解先说结论数据库管理工程师这个岗位笔试考察的核心不是你会多少种数据库产品而是你有没有建立一套完整的数据库工程思维。很多同学以为DBA就是会写SQL、会装MySQL实际上校招笔试的出发点完全不同——面试官想通过试卷判断你有没有能力在真实生产环境里把数据库管好、用好、救回来。从岗位JD反推数据库管理工程师的日常工作可以拆成四块一是数据库的架构设计与选型比如业务读多写少该上什么架构数据量涨到百万级要不要分库分表二是日常运维保障包括监控告警、备份恢复、参数调优、版本升级三是SQL与性能优化比如慢查询分析、索引设计、执行计划解读四是异常应急处理比如主从延迟、死锁、磁盘满了怎么办。对应到笔试这四块能力会转化为四个方向的题目基础原理题考察你对数据库内核机制的理解程度、SQL实操题考察你写SQL和优化SQL的能力、方案设计题考察你在真实业务场景下的架构与运维设计能力、以及一部分系统综合题考察操作系统、网络等基础设施知识的扎实程度。这里提醒准备的同学注意一个误区不要以为笔试只是走个过场机试过了还有面试。笔试成绩在后续流程里很重要尤其对于DBA这类技术岗位笔试分数直接决定了面试官对你的第一印象甚至在排序的时候会作为重要参考。所以笔试不是随便刷刷题就行的事。1.2 笔试与面试的分工不同别用面经思路准备笔试我见过不少同学拿着面试题库去准备笔试这就搞错方向了。面试可以靠聊——面试官会引导你你说出大概思路他就能判断你的水平。但笔试完全是写没有提示、没有引导你在纸上写出来的每一个结论、每一段SQL、每一个参数都被视作你真实的水平。所以笔试考察的是更加细节、更加量化的知识。举个例子。面试可以问MySQL的索引底层结构是什么你回答B树就过关了但笔试会把题目出成为什么InnoDB选择B树而不是B树或哈希索引这就是两种考察深度。再比如索引失效的题目面试会问你遇到过哪些索引失效的场景你可以举例但笔试会直接给你两三条SQL让你判断哪条能走索引、哪条不能走还要解释原因。这就逼着你把底层原理真正吃透不能停留在背诵结论的层面。另外笔试还有一个隐性目的考察你的工程习惯。大厂的校招笔试通常会有一定量的多选题和场景题题目本身不难但会在选项里埋坑用来筛选掉基础不扎实的人。还有一类题是给你一段线上业务的背景描述让你去设计解决方案这种题没有唯一答案考察的是你的思考框架是否完整、边界条件是否考虑周全。2. 基础原理储备高频考点与核心理解方式2.1 索引部分不只是背B树而是理解设计动机索引相关的内容在数据库管理工程师笔试里几乎是必考的而且分值占比不低。高频考点集中在几个方面B树的结构特点与优势、聚簇索引与非聚簇索引的区别、联合索引的最左前缀原则、索引失效的常见场景、覆盖索引与回表的理解。我建议不要死记硬背结论而是从设计动机去理解。比如B树为什么比B树更适合做数据库索引关键在于两点一是B树的数据都存放在叶子节点并且叶子节点之间用链表连接这让范围查询变得非常高效——你只需要找到起点然后沿着链表顺序往后读就行而B树的节点内部会存储数据导致中序遍历需要在不同层级的节点之间来回跳范围查询性能差很多。二是B树的非叶子节点不存数据只存索引键所以同样的页大小可以容纳更多的索引项树的高度更低磁盘IO次数更少。笔试里还经常出现一类题给你一条SQL判断是否走索引以及为什么。这类题就需要把索引失效的场景全部吃透。常见的索引失效场景有这么几类对索引列进行了函数运算或表达式计算比如WHERE DATE(create_time) 2023-01-01隐式类型转换导致索引失效比如某列是varchar类型但查询条件用了数字LIKE前缀模糊查询比如LIKE %关键词联合索引不满足最左前缀原则使用OR连接非索引列。要特别提醒的是判断索引是否失效不是只看规则还要结合数据量和优化器的选择。有时候即使条件满足走索引的条件但如果优化器估算全表扫描成本更低它也会放弃索引。笔试题如果出到这种深度通常会在题目里给出表数据量的描述你要能根据数据量级做合理判断。2.2 事务与锁隔离级别、MVCC和死锁是三类核心题事务相关知识点在笔试中占比也很高。核心考点包括ACID特性、隔离级别的定义与问题对应关系、MVCC的实现机制、锁的类型与兼容矩阵、死锁的产生条件与排查思路。先说隔离级别。四档隔离级别——读未提交、读已提交、可重复读、串行化——要背清楚但更要紧的是理解每一档解决了什么问题、又会引入什么问题。很多人背结论背得很熟读已提交解决脏读可重复读解决不可重复读串行化解决幻读。但如果笔试题目换个问法比如可重复读隔离级别下InnoDB如何解决幻读问题很多人就答不上来了。这里的关键是搞清楚加锁方式上的差异可重复读下InnoDB通过间隙锁gap lock和临键锁next-key lock来锁定范围阻止其他事务在该范围内插入新记录从而解决幻读。MVCC这块需要理解三个核心概念隐藏字段DB_TRX_ID、DB_ROLL_PTR、undo log版本链、ReadView。笔试常考的问题是在不同隔离级别下ReadView的生成时机有什么区别。简单说读已提交每次SELECT都会生成新的ReadView因此能读到其他事务已提交的最新数据可重复读只在第一次SELECT时生成ReadView后续复用同一个快照因此整个事务期间看到的数据是一致的。这个区别是理解两种隔离级别行为差异的核心。死锁相关的题目也经常出现。笔试一般不会让你去现场调试死锁而是给你一个场景判断会不会死锁、为什么死锁以及如何避免。这类题考察的是对锁兼容矩阵的理解和加锁顺序的分析。一条非常实用的经验是事务里对多个表或多个索引范围的加锁顺序要一致否则就容易出问题。2.3 日志机制binlog、redo log、undo log各有分工日志是数据库管理工程师笔试里比较有区分度的考点。很多同学对索引、事务都很熟但一聊到日志就含糊了。笔试恰恰喜欢考这些模糊地带。首先要分清三份日志各自的作用。redo log是InnoDB存储引擎层的事务日志记录的是物理页面的修改操作用于崩溃恢复保证事务的持久性undo log也是InnoDB存储引擎层的记录的是逻辑日志用于事务回滚和MVCC多版本控制binlog是MySQL Server层的二进制日志记录的是逻辑操作比如更新了某行数据为某个值用于数据复制和数据恢复。笔试常见的考法有这么几种一是问你redo log为什么需要配合binlog使用这里要引出两阶段提交prepare阶段、commit阶段二是给你一个场景比如数据库崩溃了问你哪些日志能用来恢复数据三是问主从复制依赖的是哪份日志——答案是binlog。两阶段提交这个点笔试特别喜欢考而且经常以流程图分析的形式出现。简单说要理解事务提交时InnoDB先写redo log并标记为prepare状态然后MySQL Server写binlog完了之后InnoDB再把redo log标记为commit状态。为什么需要这个两阶段因为要保证redo log和binlog两份日志的一致性。如果不用两阶段可能出现redo log写了但binlog没写的情况崩溃恢复后主库有这条数据、从库没有主从数据就不一致了。3. SQL实操题常见题型与拿分细节3.1 分组聚合与联表查询笔试SQL题的基本盘数据库管理工程师笔试里的SQL题一般是必做题而且是可以在短时间内快速拿分的部分。题型通常分几类基础增删改查、分组聚合、多表联查、子查询、窗口函数。难度一般不会超过互联网公司日常开发的实际需求但会设计一些容易踩坑的细节。比如分组聚合题经常考的一类坑是WHERE和HAVING的使用区别。简单说WHERE是在分组之前过滤行记录而HAVING是在分组之后过滤组记录。如果你的过滤条件里用了聚合函数比如查询平均分大于80分的班级那必须用HAVING因为AVG()是在分组后计算出来的WHERE根本拿不到这个值。但如果面试官换一种问法叫你写查询2023年入学且平均分大于80分的班级那就需要把时间条件放在WHERE里先过滤再把班级平均分的条件放在HAVING里过滤两个都不能少。联表查询是另一个必考重点。笔试会考察INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL JOIN的区别以及ON和WHERE条件放置位置不同带来的结果差异。这个差异说穿了还是过滤时机的问题。LEFT JOIN中如果ON条件里的过滤不匹配左表记录仍然会保留只是右表字段为NULL如果把这个条件放到WHERE里那等价于把不匹配的行过滤掉LEFT JOIN的效果变成了INNER JOIN。这个坑在笔试选择题里经常作为干扰项出现。我在阅卷的时候发现一个普遍现象很多同学在联表时会习惯性地用逗号隐式连接比如SELECT * FROM a, b WHERE a.id b.a_id。这种写法虽然能跑出来但在笔试中建议还是显式写成JOIN ... ON ...。原因是显式连接的语义更清晰阅卷人也更容易判断你的思路而且一些复杂的题目比如三表四表联查隐式连接的WHERE条件会变得非常混乱容易出错。3.2 窗口函数连续问题和TopN问题的标准解法近几年数据库管理工程师笔试中的SQL题窗口函数出现频率明显上升。如果你还只会用GROUP BY很多题写出来会非常绕甚至写不出来。窗口函数的核心价值在于它能在不合并行的前提下对每一行数据进行基于分组或全量的计算解决了分组后还要保留明细行这类问题。最常见的窗口函数题有两类。第一类是TopN问题比如查询每个部门薪资排名前3的员工。这类题的标准解法是使用ROW_NUMBER()或RANK()配合PARTITION BY。比如这样写SELECT department_id, employee_name, salary FROM ( SELECT department_id, employee_name, salary, ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rn FROM employee ) t WHERE t.rn 3;这里要注意一个细节ROW_NUMBER()、RANK()和DENSE_RANK()三个函数的差异。ROW_NUMBER()是纯粹的物理排名即使薪资相同也会分出1、2、3RANK()在遇到并列时会跳过后续的名次比如两个人并列第一下一个就是第三名DENSE_RANK()在遇到并列时不跳过名次按1、1、2这样排。笔试如果问获取每个部门薪资前三且允许并列这类需求你就需要根据题意选择合适的函数这就是刻意设计的区分点。第二类是连续问题比如查询连续登录3天以上的用户。这类题目如果用手工循环很难写标准解法是利用日期减去行号的思路。原理是如果用户连续登录那么登录日期减去一个递增的行号会得到一个不变的值一旦中断这个值就会改变。于是问题就转化为按用户和这个差值分组统计每组的天数。这类题在笔试里属于压轴SQL题但思路掌握了之后其实套路非常固定。实际写SQL时还要注意线上笔试环境一般会提供数据表样例和运行环境你可以在本地先跑通再提交。如果笔试环境不支持你反复调试那就先在草稿纸上把逻辑理清楚注意表名、字段名的大小写以及必要的分号和空格避免低级语法错误。3.3 SQL优化题从执行计划反推优化手段除了写SQL数据库管理工程师笔试还会考察SQL优化的能力。常见出题方式有两种一是给你一条慢SQL让你分析原因并给出优化方案二是给你一段执行计划的关键信息让你判断瓶颈在哪里。先说慢SQL分析。拿到一条慢SQL标准的思考顺序是先看表结构和数据量判断是否缺少索引再看WHERE条件和JOIN条件检查是否有隐式类型转换、函数运算导致索引失效然后看SELECT列的字段判断是否存在不必要的回表最后看ORDER BY和GROUP BY确认是否有额外排序。举个例子。一条常见的慢SQL是SELECT * FROM orders WHERE order_status 1 ORDER BY created_at DESC LIMIT 20;如果orders表有几百万行order_status区分度不高created_at上又没有索引这条SQL大概率会走全表扫描然后filesort排序。优化思路是什么如果业务上只关心待处理订单可以考虑在order_status和created_at上建联合索引这样既可以利用索引过滤状态又可以通过索引完成排序避免filesort。如果待处理订单本身占比很小索引效果会很明显但如果状态字段区分度很差比如90%的订单都是状态1那这个索引的意义就不大可能需要考虑其他方案比如按时间分表或使用汇总表。再补充一个笔试中的高频点执行计划里的type字段从好到差大致是system const eq_ref ref range index ALL。笔试喜欢让你判断一条SQL的执行计划是哪种类型或者从执行计划倒推查询为什么慢。这里有一个容易混淆的点range和index的区别range是索引范围扫描比如WHERE id BETWEEN 100 AND 200只扫了一部分索引index是索引全扫描比如SELECT id FROM table遍历了整个索引树。两者都是走索引但性能和定位完全不同。4. 方案设计题备份恢复、高可用与容灾设计框架4.1 备份与恢复设计用RTO和RPO指标倒推方案方案设计题是数据库管理工程师笔试的区分度所在也是后续面试的必问题型。这类题不会让你写具体的代码而是给你一个业务场景让你设计一套方案。常见的场景包括备份恢复方案设计、高可用架构设计、大表清理方案、数据迁移方案、容量规划等。先讲备份恢复。这类题的目标很明确在给定条件下设计一套能满足业务容灾需求的备份体系。做这类题有一个非常实用的入手点就是先明确两个核心指标RTO恢复时间目标和RPO恢复点目标。RTO是故障发生后业务最多能容忍多久没数据可用RPO是故障发生后最多允许丢失多少数据。举个例子。如果业务要求RTO在30分钟以内RPO在10分钟以内那每天凌晨一次全量备份肯定是不够的——最坏情况下要恢复到昨天凌晨的数据丢失一整天RPO远远超标。这时候就需要在全量备份的基础上增加定期增量备份或binlog备份把恢复窗口缩短到分钟级别。同时为了让恢复过程足够快备份文件最好是物理备份而不是逻辑备份因为物理备份的恢复速度要快得多。具体到方案可以这样写每天凌晨2点做一次全量备份同时开启binlog并保留最近7天的binlog每10分钟做一次增量备份或者使用binlog同步到异地存储恢复流程是先恢复最近的全量备份再按时间顺序重放增量备份或binlog日志最终恢复到故障前10分钟以内的状态。整个方案要说明RTO可以控制在什么水平、RPO可以控制在什么水平并且要说明如果RPO必须为零需要引入其他机制比如半同步复制或者SR同步复制技术。4.2 高可用架构设计从单点到多节点演进高可用方案设计也是笔试常客。题目场景一般会给出业务规模和发展预期让你设计主从架构或集群方案。回答这类题核心是掌握常见架构的演进路径和各自适用场景。从单体到高可用最常见的是一主一从或一主多从架构。主库负责写从库负责读通过binlog复制保持主从数据一致。面试官或者阅卷人期待你回答的不只是这个拓扑结构还包括主库故障怎么切换、从库故障怎么处理、主从延迟怎么办、脑裂怎么防止。比如主库故障需要把从库提升为新的主库这里就涉及判断主库是否真的挂了、如何避免两个库同时写入的脑裂问题。在此基础上如果业务量继续增长可能需要考虑数据库中间件来做读写分离和分库分表。笔试中常见的分层是先用Proxy做读写分离解决读扩展问题再按业务维度分库把不同业务的数据拆开或者把核心表按时间或ID范围做分表。分库分表之后还会引入新的问题比如跨库JOIN变得困难、分布式事务复杂度上升、全局唯一ID方案选择等。笔试题目如果给出这些追问你需要展示出对应的解决方案比如通过冗余字段避免跨库JOIN采用事务消息或TCC方案处理分布式事务使用雪花算法生成全局ID。高可用方面还有一个高频考点主从复制的原理。简单说主库把数据变更写入binlog从库的IO线程拉取binlog并写入本地的relay log再从库的SQL线程读取relay log并回放。笔试可能考半同步复制和异步复制的区别。异步复制下主库提交事务不等待从库确认所以主库故障时可能丢数据半同步复制要求至少一个从库收到binlog并写入relay log后才能提交所以能大幅降低数据丢失风险但会增加提交延迟。理解了这些区别才能在不同业务场景下做出合理选型。4.3 大表清理与数据迁移边界条件比方案本身更重要方案设计题经常会有一些隐蔽的边界条件阅卷人真正想看的是你有没有把这些边界条件考虑进去。以大表清理为例题目可能这样出orders表有1亿行数据需要清理一年前的历史数据怎么做常见的错误答案是直接把一年前的数据DELETE掉。这个方案在数据量少的时候没问题但上亿行的删除操作会引发几个严重问题单条DELETE会加锁事务变大后持有锁的时间很长可能拖垮线上性能大量undo log会产生磁盘空间和回滚压力都很大主从同步延迟也可能因此飙升。一个更稳妥的思路是分批量删除比如每次只删除1000条循环执行同时在业务低峰期进行。进一步如果表本身已经很大单表上亿行不管怎么删DELETE的代价都不低还容易导致表碎片化。更优雅的方式是使用分区表按时间分区清理时直接DROP掉整个分区代价极低。或者通过新建表数据重放的方式切换表在业务侧配合完成数据清理。数据迁移方案题也类似常见场景是把MySQL数据迁移到新的硬件或新的版本整个过程要保证业务不中断、数据不丢失。这里就需要按步骤设计方案先用全量工具把数据同步到新库再开启增量同步追平数据然后在业务低峰期进行切换最后通过校验工具对比两边的数据是否一致。每一步都要明确检查点和回退方案。记住一个原则方案设计题里边界条件往往比主流程更重要。5. 实战应考策略题型分布、时间分配与答题顺序5.1 合理分配时间先拿基础分再攻坚难题数据库管理工程师的笔试形式一般是限时在线作答常见时长在90到120分钟题目包含单选题、多选题、填空题、SQL编程题和方案设计题。题型分布不同作答策略也要相应调整。我个人的建议是优先保证基础题的正确率再花时间去做综合设计题。选择题和填空题虽然分值小但数量多总体占分并不低而且往往是送分题只要你基础扎实就能拿稳。SQL编程题属于中等难度建议在基础题做完之后优先处理因为SQL题只要思路对、语法对得分率很高。方案设计题放到最后这类题耗时最长而且就算时间不够只要你把框架搭出来、关键点写出来也是能拿不少分的。时间分配上假如笔试总时长120分钟可以这样安排前30到40分钟解决选择、填空和判断题中间50到60分钟写SQL题包括调试最后20到30分钟处理方案设计题就算压哨也要把核心思路和拓扑写清楚。这个节奏不是绝对的但基本逻辑是优先保住稳的分数不要在一道题上死磕。我当年见过一个反面案例有个同学在第一道多选上纠结了20多分钟结果后面的SQL题和设计题都没时间写。笔试分数不是按单题满分来排的是按整体正确率来排的为了一道题丢了一整块分数非常不划算。5.2 笔试过程中的细节陷阱不要只在SQL编辑器里栽跟头线上笔试的环境和本地IDE不完全一样这里有几个实际踩过的坑提前说一下。第一注意SQL提交格式。有些平台要求每条SQL单独提交有些平台是让你在同一个输入框里写多条SQL用分号分隔。在草稿阶段就要关注平台的说明否则一条SQL写错可能导致整段判题失败。第二注意表名与字段名的大小写。笔试平台一般不区分大小写但表名字段名尽量和题目完全一致才是稳妥的。SQL题如果跑不通浪费的调试时间相当宝贵。第三选择题里特别留意以下说法不正确的是这类否定式提问。这类题目的干扰项会把看上去正确的错误说法放在里面你需要逐一判断。建议在读题时先把不正确三个字圈出来否则很容易被带偏。第四方案设计题不要只写文字描述。如果题目没有明确限制可以用简单的ASCII箭头来画架构图比如App - Proxy - MySQL主库/从库这种表达方式在阅卷时比纯文字更清晰能帮你更快拿到采分点。5.3 一个通用的笔试答案自查清单每次交卷之前建议快速过一遍以下要点可以少犯很多低级错误SQL关键词和字段名拼写是否正确大小写是否统一。分组聚合里过滤条件是不是在HAVING里而不是误写进WHERE。JOIN类型是否选对ON条件是否完整有没有遗漏关联字段。方案设计题里是否明确写了RTO和RPO是否提到了故障切换流程。多选和判断这种带陷阱的题型有没有漏选或错选。时间计划有没有被打乱设计题是否留出了至少15分钟。最后再分享一个我自己的经验。笔试准备不能只停留在看题和背答案一定要动手写SQL、动手画方案。有些知识你看书的时候觉得懂了真让你在90分钟里默写出一份完整的SQL或者画出一套高可用方案完全不是一回事。建议至少拿出3天时间把索引、事务、日志、主从复制、备份恢复这几个核心模块的知识体系分别整理成自己的树状图再配合笔试题库做专项训练。这个过程是枯燥的但数据库管理工程师笔试从来都不是靠押题就能过的它是你整个知识体系硬实力的体现。
