1. 一份2018年的校招笔试卷今天还值得拿出来逐题拆吗先说说我为什么要把这份老题库翻出来。2018年网易的校招笔试卷放到今天看表面上是“过时”的——数据库版本迭代了好几轮云原生数据库成了主流国产数据库也站上了台面。但如果你真的从事数据库方向或者正在准备校招面试你会发现一个事实数据库管理工程师这个岗位的核心能力画像这些年几乎没有变过。原因不复杂。数据库工程师的日常工作无非就是那么几块SQL写得对不对、表设计得合不合理、索引用得准不准、事务隔离级别调得对不对、备份恢复方案靠不靠谱、高可用架构能不能扛住故障。这些能力对应的考察点在2018年的笔试卷里出现在2025年的笔试题里照样会出现只是换了一层皮。我当年备考的时候也刷过不少大厂的数据库笔试卷网易这套题有几个特点让我印象很深考察面宽但不浮夸基础题占比高实战场景题出得很有水平不是靠背概念就能蒙混过关的。也正因为如此这份试卷很适合作为数据库方向校招复习的“能力框架图”来用。这篇文章我会按照这份笔试卷背后映射的能力模型来拆解不按题号逐题罗列——因为那份题具体内容已经不重要了重要的是它考你的那几件事以及你面对这些考察点的时候应该怎么准备。适合看这篇文章的人有三类正在准备数据库相关岗位校招的同学刚入行、想把数据库基础打扎实的后端开发以及像我一样做DBA、想系统性梳理一下自己知识体系的人。下面进入正题。2. 从SQL基本功到表设计笔试卷第一关的隐藏门槛2.1 增删改查只是入场券真正的考点在细节笔试卷开头几题通常会给一段建表语句和几条查询需求让你写SQL。看起来简单实际上这部分题目的区分度非常高。你以为考的是SELECT、INSERT、UPDATE、DELETE实际上考的是你对SQL语义边界的理解。举几个典型的例子分组聚合之后怎么过滤HAVING和WHERE的先后关系、LEFT JOIN时ON和WHERE的过滤时机、NULL值参与比较运算结果是什么、COUNT(*)、COUNT(1)、COUNT(字段)三者的差异。这些点单拎出来任何一个都能让一批人栽跟头。特别是NULL的语义我面试候选人的时候必问。很多人写WHERE name ! 张三就想当然地以为把name为NULL的行也排除了实际上NULL和任何值比较的结果都是UNKNOWN不会进入结果集。如果你在笔试卷上遇到“统计表中name不为张三的记录数”正确写法要显式加上IS NULL的判断条件——这种题就是典型的“看起来简单做起来暴露功底”。2.2 范式设计题背后的业务思维表设计类的题目通常会给一个业务场景问你表该怎么建、要不要拆分、冗余字段合不合理。这类题考察的不是你能不能背出第一范式到第三范式的定义而是你能不能在实际场景中做出合理的权衡。举个例子一个订单系统订单表和用户表分开是常态但要不要把用户名冗余到订单表里从范式理论讲用户名属于用户表订单表存user_id就够了查询时JOIN用户表拿用户名。但从实际业务看订单表一旦量大JOIN就是性能瓶颈冗余一个用户名字段用空间换查询性能在报表查询频繁的场景下是完全合理的。这就是第三范式和反范式之间的取舍。笔试卷里这类题考官想看的不是你“死守范式”而是你说得出“为什么这么设计”的完整理由链查询频率、数据更新频率、数据量级、一致性要求这些因素怎么影响你的设计决策。还有一类常考的是主键设计。自增主键、UUID主键、雪花算法ID每种方案都有代价。自增主键写入性能好、页分裂少但分布式场景下会冲突UUID全局唯一但随机写入会导致B树索引页频繁分裂雪花算法兼顾唯一性和有序性但要处理时钟回拨。如果能把这些底层机制讲清楚笔试分数不会低。2.3 表设计题里容易忽略的三个工程细节第一个是字符集和排序规则。一套系统中如果有的表用utf8mb4、有的用latin1JOIN时索引会失效甚至报错。笔试题如果出现中文排序或者表情字符存储的需求考察点一定是utf8mb4而不是utf8。第二个是时间字段的类型选择。DATETIME、TIMESTAMP、BIGINT存毫秒时间戳各有利弊。TIMESTAMP有2038年问题DATETIME没有BIGINT灵活但代码层要处理时区转换TIMESTAMP会自动跟随数据库时区。实际生产环境我见过太多因为时间字段类型选错导致的数据混乱事故。第三个是预留字段问题。很多人喜欢在表里留几个reserve1、reserve2这样的字段美其名曰扩展性。这在笔试卷里如果作为判断题答案是明确的不应该。预留字段既浪费存储又让代码可读性变差还容易埋下类型不匹配的坑。真要加字段用ALTER TABLE加就是了生产环境锁表时间的问题另说至少比预留字段方案干净得多。提示遇到表设计题回答的套路应该分三层——“基础方案是什么、为什么这么做、在什么场景下需要变通”。只答第一层拿不到高分。3. 事务、锁与并发控制区分“会用数据库”和“懂数据库”的分水岭3.1 隔离级别四个档位笔试考的是“选择的代价”事务隔离级别这部分笔试卷几乎必出。一级考点是四个隔离级别分别是什么——读未提交、读已提交、可重复读、串行化。二级考点是每个级别解决了什么问题、引入了什么问题——脏读、不可重复读、幻读。三级考点也是拉开差距的地方是在具体业务场景下怎么选。我见过太多人把“MySQL默认隔离级别是可重复读”背得滚瓜烂熟但问“为什么默认是它”就答不上来。Oracle、PostgreSQL默认是读已提交MySQL默认是可重复读这背后是历史原因MySQL的binlog在早期只支持STATEMENT格式如果隔离级别是读已提交主从复制会出现数据不一致所以InnoDB把默认隔离级别设成了可重复读。后来binlog支持了ROW格式读已提交也安全了但默认值一直没改。笔试如果出场景题比如“一个转账系统适合什么隔离级别”正确答案不是让你背默认值而是让你分析转账系统的核心要求是金额不能错读已提交就够用了——因为每条SQL语句只能看到已提交的数据不会读到中间状态可重复读在事务内多次读取结果一致但这个语义在转账场景里不是硬需求。反过来如果是一个“对账系统”同样的查询在一个事务里要做多次可重复读就有价值。再往深一层不同隔离级别的性能差异本质上来自锁的粒度。读已提交下普通SELECT走MVCC快照读不加锁写操作只锁住涉及的行可重复读在InnoDB里除了行锁还要加间隙锁防止幻读。间隙锁是性能和并发度的隐形杀手——你执行一个WHERE id 100的UPDATE可能把整个区间的插入操作都锁住。3.2 死锁题笔试真正想考的是你的排查思维死锁相关的题目在笔试卷里通常是“分析以下两条SQL的执行流程判断是否可能死锁”。这类题要拿分需要你画得出加锁顺序。经典的案例是两个事务互相持锁等待事务A先更新user表某行再更新order表某行事务B先更新order表某行再更新user表某行两边各持一把锁不放就死锁了。但笔试还有更隐蔽的考法单个事务内部的一条UPDATE语句也可能因为锁的获取顺序导致死锁。InnoDB在更新多行时锁是一行一行获取的。如果SQL语句里有排序导致两个事务以不同的顺序锁定同一批行就可能死锁。实际笔试答题的时候要拿出“排查链路”的思路来确定每条SQL的执行计划估算哪些索引会被用到——这决定了锁是加在聚簇索引还是二级索引上画出每个事务的加锁顺序找到两个事务之间的循环等待关系提出解决方案调整SQL执行顺序、缩短事务时间、降低隔离级别或使用等锁超时参数这套思维不只是为了考试。我实际处理过线上死锁告警最后定位到原因是有个定时任务和前台业务对同一张表的同一批数据执行了顺序相反的UPDATE操作。解决方案不是改业务逻辑而是让定时任务也按主键顺序更新死锁就消失了。3.3 MVCC笔试卷里“不点名但常出现”的隐形考点很多事务相关的题目表面在考隔离级别实际在考MVCC。MVCC多版本并发控制是InnoDB实现读写不互斥的基石不理解它很多事务现象你只能死记。简单说MVCC让每个事务通过版本链看到数据库的一个“快照”。读操作不加锁写操作加锁读写之间不阻塞。可重复读和读已提交在InnoDB里的差别本质上就是快照生成的时机不同读已提交是每条SQL执行时生成新快照可重复读是事务内第一条SQL执行时生成快照之后一直复用。笔试如果出一道“在可重复读隔离级别下事务A先查了一行数据事务B更新了这行并提交事务A再查会看到什么”答案是“还是原来那条数据”这就是快照复用的效果。但如果事务A执行的是当前读比如SELECT ... FOR UPDATE它会读到最新已提交的数据——这个区分是很多人在笔试里丢分的地方。4. 索引与执行计划SQL优化题为什么总是压轴出现4.1 从B树到索引失效原理不牢地动山摇数据量一大SQL慢就是DBA的日常。笔试卷里的SQL优化题考察的核心是索引相关的底层机制。B树的层数、聚簇索引和二级索引的差异、回表、覆盖索引、最左前缀原则、索引下推——这些概念如果你只是背定义做题必翻车因为优化题考的是“变化场景下的判断”。举个例子一张表有联合索引(a, b, c)查询条件是WHERE b 1 AND a 2这个查询能不能走索引答案是能。很多人的机械记忆是“最左前缀所以a必须在最左边”——但实际上SQL优化器会帮你调整顺序只要查询条件里包含了最左列a就够了。换个场景WHERE a 1 AND b 2b还能用到索引吗答案是不能因为a的范围条件让b的索引序失效。这是一道高频题。还有一类高频题在索引列上做函数运算导致索引失效。比如WHERE DATE(create_time) 2025-01-01如果create_time上有索引这个查询走不了索引扫描因为每一行都要先算DATE()再和常量比较。正确写法是WHERE create_time 2025-01-01 00:00:00 AND create_time 2025-01-02 00:00:00。4.2 执行计划里的关键指标比题目本身更重要笔试卷里如果有执行计划相关题目通常会给一张EXPLAIN的输出表格让你判断问题。看懂这张表有几个关键信息type列从好到差依次是system、const、eq_ref、ref、range、index、ALL。看到ALL就要警惕全表扫描。key列实际用到的索引。有时候优化器选错了索引明明有索引却没用这说明数据分布影响了优化器的判断。rows列预估扫描行数这个数字越大查询代价越大。Extra列出现Using filesort意味着排序没有走索引出现Using temporary意味着用了临时表大概率有大排序或分组操作出现Using index意味着覆盖索引这是最优情况。复习这块内容时最有效的办法不是背指标含义而是自己在本机建一张几十万行的测试表跑几个不同类型的SQL观察执行计划的变化。当年我备考时就这么干过——用存储过程往一张表里灌了几十万条随机数据然后反复测试各种查询条件把执行计划的变化规律摸了个透后来笔试遇到执行计划题基本不会错。4.3 慢SQL优化的完整分析思路笔试答题可以直接套用碰到“这条SQL很慢怎么优化”的题不要一上来就说加索引而是按顺序输出你的排查链路先看执行计划确认慢在哪一步。是全表扫描、排序慢、临时表大还是回表次数多再看SQL写法本身。函数计算、隐式类型转换比如字符串字段直接用数字条件、LIKE %xxx前缀模糊匹配这些都会导致索引失效。看数据分布。区分度高不高如果一个字段只有两个值比如性别建索引不但没帮助还会因为回表带来额外开销。分析业务侧是否可优化。查询必须实时吗能不能走汇总表、缓存、或者把实时查询改成异步计算最后才是考虑改表结构——加索引、拆表、增加冗余字段。这套思路放在笔试答题里能让考官看到你有完整的分析框架而不是背了一个加索引的万能答案。放在实际工作里它就是每天处理线上慢SQL的路径。多说一个我从实际生产里踩过的坑有一个报表查询开发说“加了索引还是很慢”我去看执行计划发现索引建了但SQL条件里对索引列做了隐式类型转换——字段是VARCHAR条件传的是数字MySQL会自动把字段转成数字再比较索引失效。手动加引号之后查询时间从3秒降到了30毫秒。这种问题笔试可能给你一张执行计划截图让你自己找问题——你不会看Extra列就找不到。5. 备份恢复与高可用DBA的日常战场也是笔试的压轴区5.1 备份策略设计全量、增量、差异的选择不是拍脑袋备份恢复的设计题在笔试卷中出现频率很高因为这是数据库管理工程师区别于纯开发岗位的核心职能之一。题目通常是一个系统每天产生约10GB的增量数据现有500GB数据要求恢复时间目标RTO不超过1小时数据丢失目标RPO不超过5分钟设计备份策略。这种题考察的知识点很清晰。全量备份每天做不现实——耗时太长、存储开销太大、备份窗口会影响线上性能。合理的方案是每周一次全量备份每天一次增量备份同时开启binlog并定期归档。恢复的时候先恢复最近一次全量备份再依次应用增量备份最后回放binlog到故障发生前的时间点。RPO和RTO的权衡是答题的关键。如果业务要求RPO0零丢失那必须用同步复制方案而不是异步备份如果RTO要求分钟级那就要有预热的备库可以快速切换。笔试答这类题要把每个方案的代价说清楚全量备份多久、增量备份多久、binlog保留多少天、恢复时需要多少步骤、每一步的耗时估算。BAT这类大厂笔试喜欢把这些和实操结合。比如问“binlog的三种格式有什么区别”“误删了整张表的数据怎么恢复”之类。回答误删除恢复问题时要讲清楚完整链路如果有全量备份加binlog先恢复到误删前的时间点再导出误删的那几张表的数据导入生产环境。涉及的可能是一整套流程不只是单条命令。5.2 主从复制与高可用架构的考察重点高可用方向笔试常出现主从复制相关的题。初级考法问主从复制的原理主库把变更写入binlog从库拉取binlog写入自己的relay log然后回放。中级的考法问异步复制、半同步复制、全同步复制的区别——异步复制延迟可能较大主库崩溃未同步的数据在从库上也不存在半同步复制要求至少一个从库收到binlog才返回提交成功能在主库故障时保证不丢数据但会牺牲一些写入延迟全同步复制保证所有从库都提交了才返回可用性会受影响。高级的考法会直接给场景主库突然宕机你怎么做故障切换主从延迟过大时的切换策略是什么怎么选新主库这里就涉及MHA、Orchestrator之类的工具或者云数据库自带的高可用切换机制。答这些题的关键是表达出“切换不是拍脑袋选一个从库就行”——你要考虑从库的binlog位置、是否有未回放完的事务、数据一致性校验怎么做。5.3 一个常被忽视但笔试很爱出的点备份恢复的验证除了备份方案本身千万别忽视“备份是否可用”这个维度。好多人设计了一整套备份策略却从来不验证备份文件能不能成功恢复。生产环境真到故障一恢复发现备份文件损坏或恢复流程跑不通就追悔莫及了。笔试如果问你“备份策略需要考虑哪些因素”加上一条“定期进行恢复演练”是绝对的加分项。因为它体现了你对备份工作本质的理解——备份的本质不是生成了一个文件而是具备随时能把数据恢复出来的能力。从这个角度解释备份策略答题层次一下就上去了。注意任何备份方案如果你没有亲自演练过恢复流程那这套方案就不能认为“可用”。这是我从一次线上事故中得到的教训——那次我们庆幸地发现备份文件还能用但恢复耗时比预期多了一倍差点没赶上RTO。从那以后每次调整备份方案我都会在测试环境完整跑一遍恢复流程。6. 从硬核基础到国产数据库生态笔试内容正在发生什么变化6.1 Oracle和MySQL的考察侧重差异很明显2018年的笔试卷还有一个特点考察重点仍然偏向MySQL和Oracle两大体系。虽然题量可能不多但两者之间考察方向是不同的这个规律现在也没变。Oracle侧重点在于体系结构SGA/PGA、表空间管理、RMAN备份、物化视图、Flashback、AWR报告分析——这些偏“企业级管理”的能力。MySQL侧重点则是InnoDB存储引擎原理、索引机制、复制、日志系统binlog、redo log、undo log、SQL优化、与高并发直接相关的话题。如果你准备笔试时有精力最好把两者差异定位清楚。MySQL考察的是互联网高并发场景下的处理能力Oracle考察的是企业级系统稳定性和运维管理能力。面试官问你的问题往往也就隐含了未来业务的技术栈方向。6.2 国产数据库的崛起在校招笔试里慢慢有了声量这些年国产数据库发展很快——达梦、人大金仓、GaussDB、OceanBase、TiDB这些词开始频繁出现在热搜和招聘JD里。放到2018年可能还是个别题目的背景放到今天的校招笔试里已经成为一个不可忽视的方向。从笔试准备的角度看这部分不是要你把每款国产数据库的源码都读一遍而是要理解它们的定位差异成熟的企业级产品通常和Oracle的兼容性做得比较好语法迁移成本低分布式数据库侧重扩展性和金融级高可用云原生数据库讲究存储计算分离。更值得关注的是这些国产数据库在底层原理上并没有颠覆性地脱离传统关系型数据库的基本理论。它们依然要处理MVCC、锁、事务日志、索引结构这些问题。也就是说你把MySQL、Oracle的基础打扎实了接触国产数据库的定位和差异会非常快。笔试中如果出现“某国产数据库的架构和MySQL有什么异同”这类题本质上还是在考你的原理迁移能力。6.3 给正在备战的校招同学一点实际建议结合这些年我看过的简历、面试过的候选人以及数据库社区里大家经常讨论的情况给准备数据库方向校招的同学三条具体建议第一把“动手实验”作为复习主方式。只看书看文档知识点是零散的。自己在本地装个MySQL实例建一堆数据量大的表把事务隔离级别、索引、锁这些概念通过实验验证一遍知识才会真正连成网。第二准备一个“故障复盘集”。把慢SQL优化、死锁排查、误删数据恢复这类场景按“现象-排查过程-根因-解决方案”的结构整理成自己的案例笔记。笔试和面试问到任何一个方向你都有话可说而且是落地的话。第三不要忽略备份恢复和高可用这两个实操权重很高的模块。笔试卷里这部分占比通常不如SQL题多但一旦出题往往是大题值得多投入时间。多数候选人在这部分的得分差异比在SQL题上的差异大得多。尾声一份试卷的参考价值不在于题目本身说实话网易这份2018校园招聘数据库管理工程师笔试卷单从题目细节看今天不一定还有同样题目出现。但它的价值在于它像一张数据库管理工程师的能力地图——你顺着这张地图走一遍SQL基本功在不在线、表设计有没有工程思维、事务并发原理通不通、备份恢复方案想得全不全基本一目了然。我后来复盘自己走上数据库这条路的过程时发现真正帮我通过笔试、面试的不是刷过的题目数量而是每一道题背后延伸出来的那一整套知识网络。备考期间我养成的习惯——遇到一个概念就去查它的底层原理和典型场景到现在依然在做。如果你正在准备相关岗位的笔试与其焦虑“题库是不是又变了”不如回到这些不变的核心能力上多做深入。数据库这个领域“懂原理的人”从来都是稀缺的。