1. 为什么一份2018年的笔试老卷今天依然值得数据库方向的同学做一遍每年校招季总有学弟学妹跑来问我数据库方向的笔试题到底考什么有没有推荐的真题我的答案里始终有同一个建议——把网易2018校招数据库管理工程师笔试卷找出来做一遍。很多人不理解觉得2018年的题目太老技术更新换代快做旧题意义不大。但我坚持这个建议是因为校招笔试的底层逻辑这些年并没有质变它考察的是你对数据库这个基础设施的理解深度而不是你追新技术的速度。数据库管理工程师这个岗位在校招里一直比较特殊。它不像开发岗那样直接考察框架和算法而是更看重你对数据存储、数据一致性、查询性能这些底层问题的认知。2018年那份试卷题型覆盖了数据库理论基础、SQL编写、事务与并发控制、数据库设计、日常运维常识几个大方向几乎是把一名合格DBA数据库管理员需要具备的基础素养完整地筛了一遍。哪怕是放到今天分布式数据库、云原生数据库已经成了面试高频词但绝大多数题目考察的原理依然是面试官判断你能不能入行的核心依据。我把这份试卷的题型和考察点大致整理了一下虽然具体题目细节记不全了但结构非常清晰题型考察方向占比感受选择题关系模型、范式、事务特性、索引原理、基本SQL语法30%左右手写SQL题多表连接、子查询、聚合、分组过滤25%左右数据库设计题ER图设计、主外键设置、范式判断、反范式应用20%左右事务/锁/并发隔离级别、死锁产生条件、MVCC基本机制15%左右运维与杂项备份恢复、权限管理、常见故障排查思路10%左右看这个分布就明白了整个卷面没有一个知识点是“偏怪难”的全靠平时积累是否扎实。那些平时只会写insert、select的同学遇到多表连接和事务题就暴露了而真正系统学过数据库原理、在校做过课程设计、自己折腾过MySQL的同学做起来会非常顺手。这篇文章我就结合这份试卷把每个板块背后的考察逻辑、答题思路和复习方法完整拆一遍。这不只是对一份老题的复盘更是一份数据库方向校招笔试的实战地图。2. 数据库基础理论的考察重点从关系代数到三大范式这些题不能靠背2.1 关系模型与关系代数半个小时的笔试题一半在考这里2018年这份试卷的选择题部分最先出现的就是关系模型和关系代数相关的问题。比如两个关系做自然连接、选择、投影之后结果是什么元组数量如何变化再比如给定两个表结构判断哪个SQL语句能正确表达某个查询需求。很多同学看到这类题就头疼因为关系代数听起来像数学课的内容离实际工作很远。可面试官为什么要考这个因为关系代数是SQL的数学基础它决定了你写出的SQL能不能被优化器正确理解和优化。如果你清楚选择操作对应WHERE子句、投影操作对应SELECT列、自然连接对应INNER JOIN ON公共列那么你写SQL的视角就不一样了——你是在用集合思维组织数据而不是在一条条地拼字符串。实际做题时这类题最常挖的坑有两个。第一个坑是自然连接与等值连接的区分。自然连接会消去重复列而等值连接不会。有一个经典陷阱题有两个关系R和SR有3个属性S有4个属性它们有1个同名列。等值连接后属性列数是7而自然连接后属性列数是6。如果题干特意强调“同名属性合并”答案一定要选自然连接。这个细节我在帮同学讲题时发现将近一半的人会忽略掉。第二个坑是选择与投影的执行顺序。笔试卷里常给出一串关系代数表达式问哪个结果和另外几个等价。比如σ条件(π列(表))关系运算顺序是自右向左如果题目要求“先过滤再取列”那么σ和π的顺序不能互换。在实际SQL里这对应的是WHERE和SELECT的先后逻辑——虽然优化器会自动调整执行顺序但在草稿纸上推导结果时一定要按表达式的顺序一步步来。复盘这份试卷时我有个强烈感受关系代数不需要死记公式重点是你能不能用自己的话解释清楚“自然连接到底做了什么”。把这个想明白了选择题基本不会丢分。2.2 范式理论从1NF到BCNF判断题目跟实际建表是两回事范式是数据库设计题的常客2018年的卷子里也有一道大题让考生判断给定表结构属于第几范式并要求分解到3NF。这道题的分值很高也是许多同学的失分点。我总结了一个非常实用的判断口诀1NF看列不可再分2NF看非主属性是否完全依赖主键3NF看非主属性是否直接依赖主键消除传递依赖BCNF看所有决定因素是否包含候选键。笔试里最常考的是2NF和3NF的区分。举一个很典型的例子一个选课表学号课程号课程名成绩主键是学号课程号。这个表里课程名只依赖课程号不依赖学号所以课程名是部分函数依赖这个表只满足1NF不满足2NF。正确做法是拆成两张表选课表学号课程号成绩和课程表课程号课程名。再举一个3NF的例子员工表员工ID员工姓名部门ID部门名称主键是员工ID。部门名称依赖部门ID而部门ID又依赖员工ID形成传递依赖所以这个表满足2NF但不满足3NF。拆法是员工表员工ID员工姓名部门ID和部门表部门ID部门名称。做这类题时有一个从实践经验中得来的建议**先在草稿纸上把候选键找出来再逐个判断非主属性对候选键的依赖方式。**这个顺序能避免被复杂的属性关系绕晕。很多同学一上来就看属性间关系结果越推越乱。面试官考范式绝不仅仅是为了让你背定义。在实际生产环境中如果表设计大量违反范式会带来数据冗余和更新异常。反过来说范式越高表越多查询时需要关联的表也越多性能反而会下降。所以笔试里偶尔还会有一道“要不要反范式”的讨论题这时候你要能说出反范式的适用场景——比如数据量巨大、读多写少、需要减少联表查询的报表系统。2.3 数据库完整性实体完整性、参照完整性、用户定义完整性这部分在2018年试卷里以选择题和判断题形式出现考察方式非常直接给出几种情况问违反了哪种完整性约束。实体完整性指主键不能为空且不能重复参照完整性指外键的值要么为空要么在被引用表中存在用户定义完整性则是自定义规则比如年龄必须大于0、性别只能取M或F。这里容易出错的是“外键能否为空”的问题。很多同学想当然认为外键必须非空其实外键为空表示尚未关联到主表记录这在业务上是允许的。但如果外键非空且在主表中找不到对应记录就违反了参照完整性。这个细节在笔试中很常考值得特别留意。3. 手写SQL题笔试卷里最能拉开差距的部分3.1 多表连接与子查询拿到题先别急着写画表结构2018年这份试卷的SQL大题给了三张表学生表student、课程表course、选课成绩表sc然后要求写出若干条查询SQL。这是校招笔试题最经典的出法几乎每家公司都会用。题目本身不难但手写SQL和电脑上写SQL差别很大——没有执行结果反馈没有提示写错一个小地方整道题就白写了。我的建议是拿到题目后先在草稿纸上画出三张表的结构和关键字段标出主外键关系再开始写SQL。别嫌这一步费时间它能帮你理清用几张表参与查询、连接条件是什么、要先过滤还是先分组。比如常见的“查询选了课程编号为2的学生的姓名和成绩”这类题。首先从题目里的“姓名”定位到student表从“成绩”定位到sc表判断需要两张表连接。然后写连接条件student.sid sc.sid。最后加上WHERE过滤选课编号等于2。整个过程只要画出了表就是流水线操作很难出错。如果遇到嵌套子查询“查询成绩比平均成绩高的学生名单”标准写法是SELECT s.sname, sc.score FROM student s JOIN sc ON s.sid sc.sid WHERE sc.score (SELECT AVG(score) FROM sc);子查询写在WHERE里标量子查询先计算平均分再比较。这种题考察的是你对SQL执行顺序的理解——实际上数据库先执行子查询再用结果对外层查询进行过滤。3.2 聚合、分组与HAVING的坑WHERE和HAVING别混用另一道高频率题是“查询每门课程的平均成绩并筛选出平均分大于80分的课程”。正确写法是SELECT c.cname, AVG(sc.score) AS avg_score FROM course c JOIN sc ON c.cid sc.cid GROUP BY c.cid, c.cname HAVING AVG(sc.score) 80;为什么不能用WHERE AVG(score) 80因为WHERE是在分组前对原始行进行过滤的而此时聚合函数还没有计算出结果。HAVING是在分组之后对组进行过滤这时聚合结果才可用。这个逻辑在笔试里是固定考点但每年都有同学写错。还有一个细节很多人没注意到GROUP BY的列要尽量和SELECT中的非聚合列保持一致。比如上面SQL中SELECT了c.cnameGROUP BY里就要带上cname。在MySQL 5.7及以上版本默认开启了ONLY_FULL_GROUP_BY模式SELECT列不在GROUP BY中会直接报错。纸面答题时可能不判这个但面试现场口述或在线编程时会被立刻指出。3.3 日常工作中我推荐把每道手写SQL都按执行顺序检查一遍做这类题目时我个人有一个习惯写完SQL后按FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY的逻辑顺序检查一遍。如果你写的每一步都能对应到表里真实的数据变化那么这个SQL基本不会错。用这个习惯去检查自己写的SQL能在笔试中减少很多低级错误。4. 事务、锁与并发控制笔试里的“逻辑题”在这些地方最烧脑4.1 事务的ACID特性别只会背四个单词事务这一块2018年试卷考了一道很典型的选择题以下哪个场景违反了事务的原子性这种题不直接问“什么是原子性”而是给出具体场景让你判断。比如“一个转账操作扣了钱但没加钱”这就是原子性被破坏——因为事务没有全部执行成功就提交了部分结果。光背四个特性的定义是不够的你得知道它们之间是有依赖关系的。原子性是基础它保证事务要么全做要么全不做一致性是目标它保证数据库的完整性约束不会被破坏隔离性是手段它通过并发控制避免多个事务互相干扰持久性是保障它确保提交后即使宕机数据也不会丢失。在实际做题时最难判断的是隔离性和一致性的区别。比如两个事务并发修改同一条记录产生脏读这到底是哪个特性出了问题严格来说脏读是隔离性被破坏一个事务读到了另一个事务未提交的数据但最终可能导致一致性被破坏如果那个事务回滚读到脏数据的事务就基于错误数据做了决策。笔试时如果题目问“违反了什么特性”优先答隔离性如果问“可能导致什么后果”再考虑一致性。生产环境里事务的ACID并不是绝对保证的数据库会提供不同的隔离级别让你权衡。所以复习事务时不能只停留在背出四个词要理解它们之间的层级关系。4.2 隔离级别与锁不可重复读、幻读的经典判断2018年试卷的事务题里最核心的是考察四种隔离级别读未提交、读已提交、可重复读、串行化分别解决哪些并发问题。这道题几乎成了数据库笔试题的“标配”考察形式通常是给你一组并发操作序列然后问你在某个隔离级别下事务A读到的结果是什么或者问“不可重复读”和“幻读”的区别是什么。很多人分不清不可重复读和幻读这里我提供一个非常直观的解释不可重复读针对的是同一行记录的update数据值发生了变化幻读针对的是新增或删除的行数据条数发生了变化。举个例子事务A先查询成绩大于80分的学生得到了100条记录事务B这时候把某个学生成绩从79改成90事务A再查一次得到101条记录。第二条新出现的记录就像“幻觉”一样这就是幻读。那么四种隔离级别是怎么解决这些问题的隔离级别脏读不可重复读幻读读未提交可能可能可能读已提交不会可能可能可重复读不会不会可能InnoDB引擎可避免串行化不会不会不会这里有一个大多数教材不会细讲、但笔试偶尔会深挖的点MySQL的InnoDB引擎默认隔离级别是可重复读但它通过间隙锁Gap Lock和MVCC机制在绝大多数情况下解决了幻读问题。所以如果有人问“可重复读能不能避免幻读”准确答案是标准SQL规范中它不能但MySQL InnoDB实现中它基本可以。笔试作答时如果你能补充一句“MySQL的RR级别通过间隙锁规避了幻读”——这个细节能让你和别的考生拉开差距。4.3 死锁四个必要条件与答题时的答题套路死锁在2018年笔试卷里是一道简答题考察形式很经典什么是死锁产生死锁的四个必要条件是什么如何避免四个必要条件要背熟互斥条件、请求与保持条件、不可剥夺条件、循环等待条件。前三个是死锁产生的必要条件真正导致循环的是第四个。因为只要系统中存在循环等待死锁就可能发生而打破循环等待是避免死锁最直接的思路。答题时的加分项是结合数据库场景给例子。比如两个事务分别持有A行锁和B行锁又同时去请求对方持有的锁这就形成循环等待产生死锁。避免方式可以答让所有事务按照相同的顺序加锁比如先锁A再锁B两个事务都按这个顺序这样就不会形成循环或者引入超时机制锁等待超过阈值就回滚其中一个事务。如果你在试卷上能同时写出“按固定顺序访问资源”和“死锁检测机制”两条说明你不是死记硬背的这道题的分数基本拿稳了。4.4 MVCC笔试可能会深挖一个细节但不能不了解2018年试卷没有直接考MVCC但考了一道和它相关的概念题在可重复读隔离级别下事务A已经读取了某行数据事务B随后修改并提交了这行数据问事务A再次读取时看到的是什么这个问题的底层逻辑就是MVCC多版本并发控制。InnoDB通过undo log维护行的多个版本每个事务有自己的read view。在可重复读级别下事务A的read view在第一次读取时生成之后所有读取都基于这个快照所以事务B的提交对它不可见。这里有一个容易被忽略的细节快照读和当前读的行为不同。上面说的是快照读普通SELECT如果事务A用SELECT ... FOR UPDATE这条当前读语句它会读取最新已提交的版本因此能看到事务B的修改。这种细微差别在笔试面试中经常被拿来“坑”人但理解了锁和MVCC的原理就不怕了。复习MVCC不需要深挖到每一行代码但至少要能解释清楚“为什么可重复读级别下读不到别的事务已提交的修改”——因为快照在第一次读取时确定了。5. 数据库设计与建模题纸上谈兵也需要一套完整的方案5.1 根据需求画出ER图概念模型到逻辑模型的转换2018年笔试卷的最后一道大题是设计题给了一个简单的业务场景比如一个学校的学生选课系统要求画出ER图再转换成关系模式并判断是否符合3NF。这个环节考察的是数据库设计中从需求到模型的核心能力。画ER图的步骤我是这么给同学拆解的提取实体名词往往是实体比如学生、课程、老师。提取联系动词往往是联系比如“选修”、“讲授”。确定联系类型一对一、一对多、多对多。学生和课程是多对多联系会产生一张关联表。标出属性实体的属性是描述它的信息比如学生的学号、姓名、年龄。所谓多对多联系这一点是高频失分点。如果学生和课程是多对多关系那么转换成关系模式时需要额外生成一张选课表学号课程号成绩主键是学号课程号联合主键。很多同学画ER图时漏了这张关联表导致后面的关系模式全错。这是笔试卷里最可惜的丢分方式。5.2 主键设计自增主键还是业务主键笔试里的讨论题怎么答2018年这份试卷在数据库设计部分考了一道“主键用自增ID还是业务字段”的讨论题。没有标准答案关键看你的分析是否全面。我的答题逻辑是分层回答如果业务字段本身稳定且唯一比如身份证号从查询效率和数据一致性角度考虑可以不额外设置自增主键但实际生产环境中更推荐使用自增ID作为代理主键因为业务字段可能有变更比如身份证号格式调整、可能被多个业务系统共用、可能会被业务逻辑修改一旦主键变了会牵动所有外键引用代价极大。这里可以补充一个笔试卷中少有人写到的细节用自增ID做主键在InnoDB里由于聚簇索引按主键顺序存储插入时通常只需要追加到页尾页分裂概率较低如果使用UUID这种随机字符串做主键插入时数据会随机分布频繁导致页分裂加剧碎片化影响写性能。这个点在答案里写出“聚簇索引的顺序性”这一层会比只说“自增ID简单好用”高级很多。5.3 反范式设计什么时候可以故意“不遵守”范式设计题里还有一个加分项主动提到反范式。比如选课系统需要频繁查询学生和课程信息如果严格按范式拆表每次查询都要关联4、5张表数据量大时性能堪忧。反范式的常见手法包括在订单表里冗余存储用户姓名避免每次查询联表用户表在统计报表表里冗余存储汇总值避免每次都实时计算。这是一种用空间换时间的取舍。但笔试作答时要强调一个边界反范式必须有意识地管理数据一致性。冗余字段可能导致同一份数据在多个地方出现更新时要记得同步修改否则会出现数据不一致。如果面试官追问“怎么解决一致性问题”可以回答“通过应用层事务或定时任务同步或者使用数据库触发器”。能答出“什么时候该反范式、反范式有什么代价、如何保证一致性”这三点这道设计题基本就是满分水平了。6. 运维与杂项题目这部分不只是考察背命令而是考察排查思路6.1 备份恢复全量备份、增量备份与binlog的结合思路2018年试卷的运维题里有一道备份策略设计题问的是“如果数据库在凌晨2点宕机你有一套每周日凌晨全量备份、每天凌晨增量备份的方案如何恢复到凌晨1点的状态”这道题的本质是考察备份恢复的完整链路。标准思路是先恢复最近一次全量备份再按时间顺序恢复全量备份之后的增量备份最后重放binlog日志把数据推进到凌晨1点。如果binlog也包含在备份中且时间覆盖完整理论上可以精确恢复到任意时间点。这里要强调一个笔试中容易被忽略的考点备份的时间点与binlog时间点的衔接。增量备份和binlog必须连续无缝否则中间会丢失一段数据。笔试题里如果给的时间点是“周日凌晨全量备份 每天凌晨增量备份”而宕机时间是凌晨2点那么你需要恢复周日全量 → 周一到周二的增量 → 周二凌晨2点之前的binlog。很多人只答到“恢复增量备份”就结束了少了binlog这一步相当于丢了一个关键采分点。6.2 索引失效的常见场景这条在面试和笔试里都高频出现2018年试卷中索引相关的选择题非常典型给出一条SQL问是否会走索引。这类题考察的是你对索引机制的准确理解。最容易丢分的几种索引失效场景对索引列使用函数比如WHERE YEAR(create_time) 2023索引失效。正确写法是WHERE create_time 2023-01-01 AND create_time 2024-01-01。隐式类型转换比如索引列是varchar查询条件用数字MySQL会隐式转换导致索引失效。使用LIKE %关键字前置通配符导致索引失效。OR连接的条件包含非索引列优化器可能放弃索引。联合索引不满足最左前缀原则比如索引(a,b,c)只查b或c用不上索引。笔试试卷里如果让你优化一条慢SQL最常见的“坑”是索引列上做了计算或函数操作。你只要把这个识别出来再给出改写的SQL这题基本就过关了。在这里我补充一个实操经验调优时先看执行计划中type字段的值从all全表扫描改进到ref或eq_ref说明索引生效了。纸上答题不一定需要你说到这一步但面试官追问时可以答出来。6.3 权限与安全管理最小权限原则是默认得分点权限管理题在2018年试卷里是一道简答题问你“给一个新同事开通只读账号应该用什么语句”。答案是GRANT SELECT ON database_name.* TO readonly_user% IDENTIFIED BY password;这类题本身简单但很多同学会忽略一个细节权限粒度控制到库表级别还是行级别一般只读账只需要到表级别但如果涉及敏感列如用户密码需要精确到列级别的授权此时语句中要写明列名。答题时如果能补充“最小权限原则”——只授予完成工作所必需的最小权限并定期回收不需要的权限——这种表述展示了你的安全意识是这类简答题的加分项。另外不要在生产环境使用root账号直接操作数据库平时开发就建一个普通账号只给需要访问的库表授权。这是很多老DBA带新人的第一课。7. 复盘后的复习地图从这份卷子反推一份校招数据库岗备考清单做完整份2018年网易笔试卷的复盘你会发现它几乎就是一份校招数据库岗的“考点地图”。相比于漫无目的地刷LeetCode数据库题更有价值的方式是把这份地图变成你自己的学习清单逐项落实。我根据自己的复习经验和带新人的体会整理了一份按优先级排列的备考清单供你参考优先级考点模块具体内容推荐练习方式P0SQL基础多表连接、子查询、聚合、分组、HAVING、窗口函数每天8-10道手写SQL题覆盖各种JOIN场景P0事务与隔离级别ACID、四种隔离级别、脏读/不可重复读/幻读用两个终端模拟并发事务观察不同隔离级别下的行为P0索引与优化B树原理、最左前缀、索引失效场景、EXPLAIN执行计划在MySQL中建大量测试数据跑EXPLAIN分析慢SQLP1范式与设计1NF/2NF/3NF/BCNF判断、ER图、主键设计、反范式找3-5个业务场景做数据库设计练习P1锁与并发悲观锁/乐观锁、死锁四条件、MVCC机制分析实际死锁日志理解锁等待和回滚P1备份恢复全量/增量/差异备份策略、binlog应用本地搭建MySQL演练全量binlog恢复P2常见问题排查连接数满、慢查询频发、主从延迟看DBA故障复盘案例形成排查思路P2前沿认知国产数据库达梦、人大金仓、向量数据库、时序数据库了解大致原理和适用场景校招笔试很少深挖但面试能加分顺带提一句搜索这些概念时经常看到“数据库课程设计”“数据库增删改查”这些词说明数据库方向的学习者大多处在打基础的阶段。如果你时间有限优先把P0的四个模块吃透校招笔试大概率就不会慌。说回工具练习。很多人问我笔试又不让用电脑平时为什么还要在电脑上练我的回答是纸上写SQL只是输出真正理解SQL的执行逻辑必须靠实际操作。你可以本地装一个MySQL往表里插入几万行数据开慢查询日志用EXPLAIN看执行计划再用两个会话模拟并发事务亲自看看不同隔离级别下脏读、不可重复读、幻读到底长什么样。这个过程走一遍比你背十遍概念都管用。8. 最后聊聊我复盘这份卷子的几个意外收获把这份2018年笔试卷完整梳理一遍之后我其实有几个实践之外的意外体会想来想去还是值得单独写出来。一个是心态上的。很多同学看到“2018年”就产生轻视心理觉得题目肯定过时了。但把题目拆开看数据库最核心的东西——关系模型、事务、索引、范式——这二十多年来基本没变过。云数据库、分布式数据库、NewSQL这些新概念本质依然是在解决数据的一致性和可用性基础原理还是那些。把老题吃透恰恰能帮你建立起一个不容易被新技术冲垮的稳定内核。另一个是答题技巧上的。手写SQL和事务分析题最容易丢分的其实是“没看清题目要求”。比如题目说“查询没选课的学生”结果你写了JOIN之后忘记加WHERE IS NULL过滤比如题目要求“统计每门课的人数”你SELECT了课程名却忘了GROUP BY课程名。复盘时我反复提醒自己每写完一条SQL都要回头去题目里核对一遍需求的关键词而不是核对语法。这个习惯救了我很多回也帮我在带人时减少了不少低级的代码review返工。最后一个收获是学习路径上的。我把这份卷子推荐给过很多准备校招的同学反馈最集中的一点是做完之后他们反而知道自己缺什么了。缺的不是某个零散知识点而是一个系统性的知识体系。比如你连表JOIN时能不能立即说出INNER JOIN和LEFT JOIN在行数上的差异你设置隔离级别时能不能说出它的底层锁机制你设计一张表时能不能判断出第五个字段需要放在哪张表如果你能对这些问题脱口而出校招笔试的数据库部分就基本不用再担心了。如果你现在看到这些问题还需要停顿一下那就从这份卷子的每个模块开始一个一个补齐。