整理网易2023校招数据库管理工程师杭研笔试的过程我最大的感触是它不是一场“背答案”的考试更像一次数据库基本功和排错思维的体检。无论你投的是MySQL、Oracle还是这些年逐渐增多的国产数据库方向笔试的底层逻辑都差不多先看你对关系模型、索引、事务这类核心概念理解得够不够透再看你能不能把原理应用到SQL调优、备份恢复和高可用架构的场景里。这篇内容适合三类人正在准备校招笔试的同学想系统梳理数据库知识点的后端开发以及刚接触数据库运维、打算向DBA方向转型的同行。我会把这场笔试背后对应的高频考点、答题思路以及我在真实业务里踩过的坑一起写出来。内容不会停留在“背概念”而是尽量还原考场上的思考路径方便你直接当作复习提纲使用。1. 笔试整体观感数据库管理工程师到底在筛什么1.1 岗位定位与考察主线网易杭研的数据库管理工程师说白了就是数据库的“负责人”。“管理”两个字在笔试里绝对不是让你背几条操作命令它更像是在筛选三种能力。第一能不能把数据库基础原理讲清楚。比如索引为什么能加速、事务隔离级别解决什么问题这部分考察的是理论是否扎实。第二能不能在真实场景里做判断。比如一个慢查询摆在面前你是通过什么步骤定位问题是索引失效还是数据量过大这部分考察的是排错思路。第三能不能放眼架构和工程。主从复制延迟怎么办、分库分表怎么选、备份是否真的可恢复这部分考察的是你是否有承担DBA职责的意识。从考点分布来看SQL编写、查询优化、事务并发、备份恢复几乎必考。和很多互联网公司的招聘风格类似它不是大学期末卷子那种“名词解释”而是希望考生在有限时间内展示“我会做”而不是“我知道”。这个定位决定了备考方向与其整本整本地刷理论书不如把每类核心题型的推演流程走一遍。1.2 笔试结构与时间分配印象按常规校招笔试形式可以推断题型基本是单选、多选、填空、简答和手写SQL的组合。选择题覆盖数据库基础、锁、日志、备份工具选型手写SQL题一般会有两三道难度从单表查询、多表连接逐步升级到窗口函数、连续登录这类比较花哨的题最后往往有一道综合题给你一个业务场景让设计表结构或排查慢SQL。建议时间分配上选择题控制在30%以内SQL题优先完成因为分值高且确定性最强。综合题不要留到最后才动手哪怕只写出思路也能拿步骤分。笔试环境通常只允许单屏没法边查资料边答题所以考前一定要把常用命令和SQL语法存在脑子里而不是靠浏览器。2. 核心原理关系模型、索引与执行计划2.1 关系模型与范式设计的考点第一次准备这类笔试时我一度觉得范式是纯理论但后来在真实建表时才发现它其实帮我们省了无数后续麻烦。校招题里常出现的范式相关考点有三个层次判断表结构属于第几范式、给出一个违背范式的问题并给出拆分方案、以及“为什么有时候要故意反范式”。第一范式的核心是“属性不可再分”第二范式要在第一范式基础上解决部分依赖第三范式解决传递依赖。笔试常拿订单记录举例子比如一个订单表里同时存了商品名称和商品分类且分类只依赖商品名称而不依赖订单那就存在传递依赖拆成商品表会更合理。但真实互联网场景里查询频繁且字段更新不频繁时我们会故意冗余一个分类名称到订单表减少join。笔试如果遇到这类讨论大胆写出“在可接受一致性成本下反范式化以提高查询性能”通常能加分因为这说明你理解理论不是教条。主键选择也常被单独拎出来问。自增主键、UUID、雪花ID各有取舍。自增主键的写入性能好、页分裂概率低但分布式环境下不推荐UUID虽然全局唯一但无序会导致随机IO冷热数据不均衡雪花ID是工程上更常见的折中方案兼顾唯一、趋势递增和部署简单。回答时可以顺手说明“趋势递增”为什么重要包括减少页分裂、保证聚簇索引的物理顺序这样答案会显得更有深度。2.2 B树索引为什么几乎所有关系型数据库都选它索引考点里最高频的一个问题是为什么MySQL InnoDB用B树而不是二叉树、红黑树或B树。这个问题最好分三个递进层次来回答。第一层树高决定磁盘访问次数。数据库索引是落在磁盘上的每次节点访问都对应一次磁盘IO。二叉树在数据量百万级时树高会到20多层每次查询要走20多次IO显然不现实。B树和B树通过“一个节点存多个键值”把树高压低三层左右就能支撑千万级数据。第二层为什么选B树而不是B树。B树把所有数据都放在叶子节点且叶子节点之间用链表相连这样范围查询可以顺着链表顺序扫描B树的数据散落在非叶节点范围查询需要反复回到父节点效率就差一些。第三层InnoDB的聚簇索引更是把B树的叶子节点直接当作数据页存储所以主键就是数据物理排序的依据这也是主键设计尽量要单调递增的原因。联合索引是最容易翻车的点。联合索引(a, b, c)生效的前提是遵循最左前缀等于说查询条件必须从a开始。题目如果问你where b 1 and c 2能不能走索引答案是不能除非查询条件里有个a参与等值判断。这里稍微容易混淆的是MySQL 8.0新特性里的“跳跃扫描”可以在一定程度上缓解但笔试里按最左前缀回答最稳妥。另外还要分清楚回表、覆盖索引、索引下推。回表是查询二级索引后再回到聚簇索引拿整行的过程覆盖索引是查询字段全部包含在索引字段里压根不需要回表索引下推是MySQL 5.6起的优化把WHERE里可判断的索引列条件在索引遍历过程中就过滤掉减少回表次数。这三个点经常是同一道题的三个填空建议绑在一起记。2.3 事务、隔离级别与MVCC的高频问答事务部分最“送分”但也最容易写错的就是ACID四个特性。A原子性、C一致性、I隔离性、D持久性。笔试喜欢问“哪个特性是由哪种日志或机制保证的”。InnoDB里原子性和持久性主要依赖undo log和redo log隔离性依赖锁和MVCC一致性则是一个整体结果由上面三者共同保证。隔离级别是绕不开的考点。READ UNCOMMITTED可能读脏数据READ COMMITTED解决脏读但不可重复读REPEATABLE READ解决不可重复读但是否解决幻读要看数据库具体实现。在MySQL InnoDB默认的REPEATABLE READ级别下通过MVCC快照读和next-key lock的配合基本能避免幻读如果你用悲观锁手动SELECT ... FOR UPDATEInnoDB会用间隙锁或next-key lock把扫描范围内的间隙锁住从而挡住插入。理解这层后再回答“MySQL默认隔离级别是什么、为什么”就顺理成章了默认RR但很多互联网团队会主动改成RC因为RR的间隙锁更容易引发死锁而业务往往可以接受RC下不可重复读的微小风险。MVCC是核心中的核心。简单讲每一行记录会有隐藏列一个保存事务ID一个保存回滚指针。读操作在RR下通过ReadView判断当前事务能看到哪个版本普通SELECT是快照读不加锁INSERT、UPDATE、DELETE是当前读必须读最新版本并加锁。死锁排查如果笔试场上让你简述思路最稳的流程是先通过SHOW ENGINE INNODB STATUS查看LATEST DETECTED DEADLOCK信息再分析事务持有和等待的锁最后往往能找到“两个事务以相反顺序加锁”这类典型场景。写答案时能带上“锁的顺序是死锁最常见的诱因”这句话会显得很有实战经验。3. SQL书写与排查实战与“坑”3.1 高频手写SQL题的套路笔试里的SQL题表面考语法实际考的是“能不能把业务语义翻译成集合操作”。增删改查是基本功其中SELECT的考察形状最多JOIN、GROUP BY、HAVING、子查询、DISTINCT、LIMIT都要手熟。我复习时把高频题型归纳成四个套路。第一类多表连接后统计比如查出每个部门的员工数和平均薪水这种题大部分人直接LEFT JOIN后GROUP BY即可但要注意JOIN的关联键是否唯一如果右表在关联字段有重复聚合结果会被放大。第二类筛选每组分组的第N条记录用窗口函数ROW_NUMBER() OVER(PARTITION BY ... ORDER BY ...)最直接。第三类连续N天登录或连续下单问题经典解法是把日期减去ROW_NUMBER()生成的分组序号日期差是同一个值的行就属于同一段连续区间。第四类null值陷阱比如查出没有订单的客户用NOT EXISTS或者LEFT JOIN加IS NULL而不是用NOT IN直接怼子查询因为子查询结果集包含NULL时NOT IN会一把返回空结果。窗口函数在近年笔试里的出现频率非常高。除了ROW_NUMBERRANK、DENSE_RANK、SUM() OVER(ORDER BY ...)、LAG、LEAD也要会。回答窗口函数题时关键是写清楚PARTITION BY和ORDER BY以及是否要限定窗口范围。校招题一般不会考太复杂的frame但累计求和这种需求要能第一时间反应过来。3.2 慢查询排查与执行计划解读手写SQL之外查询优化题几乎是数据库管理工程师的核心保留项目。实际笔试会给你一个慢查询case让你判断瓶颈并提出方案。这类题答案要落在执行计划上。MySQL里用EXPLAIN看执行计划时我最先看三列type、key、rows。type从好到差大致是const、eq_ref、ref、range、index、ALL。ALL是全表扫描这是性能问题的最大信号。key列显示实际用了哪个索引如果显示NULL说明没走索引。rows是预计扫描行数不是精确值但能做相对比较。Extra列如果出现Using filesort或Using temporary说明排序或分组没有利用好索引通常需要检查ORDER BY、GROUP BY的字段是否和索引匹配。有一次在现网排查一个报表查询要跑三秒多EXPLAIN看type是ALL加了一个联合索引后降到0.2秒但rows还是偏大。后来发现是WHERE条件里对索引字段用了函数比如DATE(create_time) 2024-01-01导致索引失效。改成create_time 2024-01-01 00:00:00 AND create_time 2024-01-02 00:00:00才真正走到range范围扫描。这类函数包裹导致索引失效的细节笔试经常以选择题形式出现做题时要盯着SELECT、WHERE、JOIN ON里有没有对字段做运算或函数处理。3.3 锁与并发场景的实战思考笔试题里不大可能让你在页面里操作数据库但会通过场景描述来考锁知识。比如题目说两个事务同时执行UPDATE同一行会发生什么这背后就是行锁排队如果UPDATE影响范围扩大行锁可能升级成表锁并发度骤降这也是为什么带LIMIT的UPDATE和DELETE要小心扫描范围大时锁的区间也大。另一个很常见的命题方向是并发扣库存设计。做法有四类乐观锁版本号、悲观锁SELECT FOR UPDATE、原子UPDATE库存字段、以及Redis预扣库存配合异步对账。笔试答题时不需要炫技先分析业务对一致性要求有多高再选方案。比如库存不能超卖多数人会优先考虑原子UPDATE因为一条SQL本身就保证原子性UPDATE stock SET count count - 1 WHERE id ? AND count 1如果不影响行数就说明库存不足。这种写法不用显式加锁也没有死锁风险非常适合作为第一版本的方案实际业务里再配合重试和日志补偿就可以上线。并发场景还有一个容易被忽视的点是数据库连接池。笔试题偶尔会让你评价连接池配置合不合理比如连接数设成200还是500。连接池不是越大越好每个连接背后都是一个线程和一个数据库会话整体配置过大会把数据库CPU和内存拖垮。像HikariCP、Druid这类连接池常见的合理配置范围在几十左右具体取决于每个查询耗时、数据库核数和网络延迟。答题时能提到“连接池大小和数据库处理能力匹配而不是越大越好”一般就能拿到区分度。4. 数据库高可用、备份与容灾4.1 主从复制与一致性问题的拆解数据库管理工程师岗位和高可用话题绑定很深。笔试不会让你搭一遍集群但会问主从复制是怎么工作的、延迟怎么解决、从库数据不一致怎么办。MySQL主从复制的核心是binlog。主库开启binlog后每个变更会写进binlog从库的IO线程拉取日志SQL线程回放形成异步复制链路。异步复制的问题是主库一旦宕机未同步到从库的数据会丢于是出现半同步复制主库在提交前等待至少一个从库确认收到binlog才向客户端返回成功用一点延迟换更高可靠性。到MySQL 5.7以后GTID成为重要基础它可以唯一标识每个事务让主从切换时找binlog点位变得简单也更方便做故障恢复。回答从库延迟怎么解决时常规思路有三条优化主库的写入方式减少单条事务过大让从库用多线程并行复制而不是单线程回放拆分读写分离把报表、数据统计这类重查询引到独立从库避免和主从同步争抢IO。如果笔试还追问数据一致性校验可以提pt-table-checksum配合pt-table-sync但重点是要说明校验的计算方式一般是对表逐行计算校验和比对主从差异后按主库数据修复。这种答案一听就是干过活的人写出来的。4.2 备份恢复与误操作处理备份是最容易在笔试里被忽略、但真实面试官最看重的话题。因为DBA的核心价值之一就是坏了能恢复。笔试常问mysqldump和物理备份有什么区别如何恢复到指定时间点。mysqldump是逻辑备份导出SQL文本可以在异构版本之间恢复但恢复速度慢适合中小数据量。xtrabackup是物理备份直接拷贝数据文件恢复速度快适合大数据量场景。无论哪种备份如果没有binlog最多只能恢复到备份时刻要想恢复到误删前的一瞬间必须把备份文件和其后的binlog一起使用。恢复流程通常是先全量恢复最近的备份再根据binlog的起始位置回放到误操作之前的position点。笔试里遇到误删整张表这种题答案里出现show master status确认binlog坐标和mysqlbinlog --stop-position这两步基本就能拿到核心分。我自己还踩过一个经典坑以为备份文件存在同一台机器的另一块盘就算安全结果整机故障后数据全没。后来做容灾设计才明白备份要异地、要定期做恢复演练而且演练结果要有记录。校招笔试如果问备份方案怎么设计一定要提到恢复演练这个概念因为只说备份策略不说恢复验证就是纸上谈兵。4.3 分库分表与架构上的取舍当单库单表扛不住增长分库分表就进入视野。笔试核心问题通常有两个怎么分以及分完之后哪些代价。垂直拆分是按业务域拆比如把用户表、订单表分别放到不同库水平拆分是把同一张表的数据按分片键散列到多个表或库。水平拆分的关键是选分片键选错了以后查询像无头苍蝇。比如说订单表按user_id分片按订单号查单条记录时就不知道数据在哪个分片需要加一张映射表或干脆全局广播。所以工程上经常把查询频率最高的维度作为分片键并提前接受其他维度查询要走汇总服务的代价。分片后的两个难点一个是全局主键一个是分布式事务。全局主键通常用雪花ID或号段模式解决号段模式就是每次从中心服务拿一段ID避免每次都请求数据库。分布式事务常见方案有2PC、TCC、本地消息表、以及柔性事务SAGA等。笔试答题不用把每个方案都展开写但至少要把强一致和最终一致两类思路说清楚XA/2PC是同步阻塞的强一致方案性能差TCC和消息表适合要求最终一致性的高并发场景。如果能再补充一句分库分表会带来跨库JOIN、分布式事务、运维复杂度上升等代价说明你对架构取舍有清醒认识。5. 容易被提问的扩展点国产数据库与新型数据库5.1 国产数据库生态的考察方向近几年校招笔试题里国产数据库相关热词明显变多比如达梦、人大金仓、GaussDB、OceanBase、openGauss、Doris。很多同学一看到国产数据库就担心要背一堆新概念其实不用慌。笔试考察的核心通常是迁移兼容性和工程师怎么低成本上手。国产数据库大体沿着两条路线演进一是兼容MySQL或Oracle语法让存量业务尽量不改代码就能迁移比如达梦对Oracle语法兼容较好GaussDB也有兼容模式二是自研存储引擎或分布式架构直接解决扩展性问题比如OceanBase的分布式事务和原生多租户能力。如果笔试让你评价国产数据库怎么选最稳妥的回答结构是先看业务是否对生态兼容有要求再看一致性、扩展性、运维社区支持最后做迁移和压测验证而不是听信厂商单方面宣传。还有一类题会把Doris和传统OLTP数据库混在一起问。这里要明确Doris是分析型MPP数据库适合大规模OLAP查询比如报表、大宽表、聚合分析但它不是用来替代OLTP事务库的。笔试如果让你画出数仓链路可以说业务库通过数据同步工具将增量数据实时同步到Doris或数仓里做分析形成读链路。这个数据同步关键词在如今校招里也很常见本质上是围绕binlog或CDC方案做实时入仓掌握这个概念比背具体工具命令更有用。5.2 向量数据库与时序数据库的热知识提到向量数据库很多同学下意识觉得这是人工智能方向才需要懂但数据库管理工程师的笔试题里也开始出现了。原因很简单大模型相关的AI应用催生了海量向量检索需求而向量数据库就是专门干这个的。它存的不再是结构化行数据而是高维向量查询方式是找最相似的向量比如图片相似度、语义检索、推荐召回。常见产品有Milvus、Chroma、Qdrant等核心考点一般是向量索引是什么常用哪些距离度量以及为什么传统B树不适合纯向量检索。距离度量主要有欧式距离、余弦相似度、内积。回答时配一句选择哪种度量取决于业务语义语义向量常用余弦相似度欧氏距离更关注绝对差异就能体现理解。索引方面常见的HNSW是图索引适合高召回率检索IVF系列通过聚类倒排粗筛适合海量数据。笔试不要求你把每个算法推一遍但能说清楚近似最近邻检索ANN牺牲少量精度换取极高召回速度已经足够。时序数据库则是另一个热词因为监控、物联网、金融行情这类数据天生按时间排列。它的写入大多是追加写查询多是按时间范围聚合所以和传统OLTP数据库的存储模型不同。时序库方案里InfluxDB、TDengine、Prometheus较为常见schema设计上通常区分tag和fieldtag是索引字段适合做筛选维度field是指标字段比如CPU使用率、温度值不要把高基数的字段放在tag里因为基数过高会膨胀索引。考场如果让你设计一张时序表能写出时间戳加tag加field的三段式结构并说明分区按时间基本稳了。6. 备考经验与笔试注意事项6.1 考前准备清单与自测路径回顾我自己的准备过程最有效的不是一遍遍翻书而是给自己搭一个可以随时实验的环境。建议准备一台装有MySQL 8.0的本地环境最好再开一个Docker容器用来测主从这样才能真正跑通EXPLAIN、慢查询日志、主从切换、备份恢复这些动作。如果条件允许用DataGrip这类GUI工具看执行计划会更直观但手写SQL和命令行操作也要习惯毕竟笔试环境不一定提供GUI。复习路径上我建议按这个顺序过一遍先快速梳理数据库原理和SQL语法花两天把索引和优化器相关的章节看掉再用题库或刷题网站练手写SQL重点练窗口函数和连续问题第三步是跑通一次完整的备份恢复流程哪怕只是小规模数据也要知道mysqldump、binlog、mysqlbinlog这三件套在命令行里长什么样最后浏览一下国产数据库、向量数据库这些新方向做到听到名词不慌。正式考试前还可以做一次限时模拟。找一套真题或类似难度题严格按90分钟或120分钟去卡时间。模拟时把答题顺序固定下来先做熟悉的SQL题快速锁定分数再做简答和综合题按结构写关键词最后处理选择题和填空这种零散项。这样能避免最后时间不够综合题草草收场。6.2 笔试过程中容易踩的失分点我在不同笔试里看到最多的问题主要有四类都是可以提前预防的。第一类是SQL语义错误。很多同学手写SQL时注意力全放在能不能跑通上忽略了聚合函数、JOIN条件、NULL值之类导致结果不对的细节。这里建议写完后心里跑一遍样例数据确认结果集合符合题意。第二类是只写结论不写过程。简答题如果只答使用索引很难拿满分数更好的答法是先看执行计划的type和key判断是否走索引再给出索引建议以及预期变化。把排查思路写成观察、分析、措施、验证四段会显得更专业。第三类是事务隔离级别和死锁这类并发题容易出现概念混用。建议在草稿纸上把四种隔离级别对应的问题、可见性、锁行为画一张表答题时边看边写。第四类是备份恢复类的题题目问了恢复到误删之前很多人只写mysqldump恢复就结束了没提binlog回放丢分很可惜。备份恢复一定要记得全量备份加binlog增量是一套组合拳。6.3 从笔试反推工程能力的一条心得整理这份复盘的过程中我越来越觉得笔试不是一件孤立的事情。它其实是把日常DBA会遇到的典型问题抽出来压缩到一场考试里。你平时如果经常看执行计划、跑过恢复演练、处理过一次生产事故遇到这些题目自然会有直觉。反过来如果只是背答案哪怕笔试过了后续面试深挖两三轮也会露馅。我个人现在的做法是每接触一个新知识点就顺手在本地建一个极简用例把它跑一遍。比如今天学到间隙锁就开两个MySQL会话手动模拟UPDATE的锁阻塞和死锁然后看SHOW ENGINE INNODB STATUS输出。这种方式虽然耗时但记忆牢固程度远高于刷题而且实战中真能救急。如果你现在还在准备校招我建议你也把能动手实验当成备考标准这样笔试和面试两关都能走得稳一些。