这场笔试是我参加过的最特别的一场校招笔试。
我们通常习惯的那种"算法题+选择题"的互联网校招套路，在网易杭研数据库管理工程师的提前批里几乎失效了。整张卷子给人的感觉不是"我在考算法"，而是"我在被审核有没有资格当一名DBA"。它不关心你能不能二十分钟写出一道hard级别的LeetCode，它关心的是你对一条SQL的生命周期到底理解到什么程度，你知不知道线上一条慢查询会以怎样的链路拖垮一个库，你有没有想过数据库崩溃之后数据是怎么回来的。
这篇文章我拖了很久才写。因为笔试结束后我复盘了很久，发现这场笔试的价值被很多人低估了。它不是一个简单的"知识测试"，而是把数据库管理工程师这个岗位的日常挑战浓缩进了一份卷子。无论你是准备网易的校招，还是想系统评估一下自己有没有做数据库方向的能力，这篇复盘都值得你花十分钟读完。
1. 岗位画像篇：数据库管理工程师到底在招什么样的人
1.1 一场"不按套路出牌"的笔试
拿到试卷的第一反应是：题型分布和我想的不一样。没有上来就甩一道hard级算法题，也没有纯八股式的名词解释堆砌。整个卷子更像是一个"数据库体检单"，从SQL基础、事务原理、索引优化，再到高可用架构、故障排查，一层一层往下探。
这其实是网易这类互联网公司数据库团队笔试的典型风格。他们不那么在意你能背多少八股文，而是想通过笔试模拟一个真实工作场景：给你一个出了问题的数据库，你会怎么定位？给你一条慢查询，你会怎么优化？给你一个数据不一致的场景，你能说出哪些可能的原因？
我印象最深的一道题，是给了一段线上环境的异常日志，让你判断最可能的原因是什么。这种题没有标准答案八股，考的就是你有没有真实的MySQL运维经验，哪怕只是阅读过相关的故障案例。如果你只是会写CRUD，没有深入过数据库的底层运行机制，这种题基本靠蒙。
1.2 DBA与后端开发：笔试考察逻辑的根本差异
这一点我觉得有必要单独拿出来说，因为很多同学在准备数据库管理工程师的时候，用的是准备后端开发岗的思路。这个方向错了。
后端开发笔试的核心是算法与系统设计能力，考察的是"你能否用代码完成业务功能"。而数据库管理工程师笔试的核心是稳定、一致、高效这三个词，考察的是"你能否让一套支撑业务的数据库长期稳定运行"。前者是建设者，后者更像是保障者。
这种差异在题目设置上体现得非常明显。后端笔试会问你如何设计一个秒杀系统，而数据库笔试更可能会问你：秒杀场景下数据库连接池的容量如何评估？热点行更新怎么避免锁冲突？突发流量下主库扛不住了，你是先扩容还是先拆分？
因此如果你只是刷题、背算法，那么数据库笔试一定会让你觉得"使不上劲"。你需要的是建立一整套关于数据库运行机制的知识框架，并且能把这些框架投射到具体的故障场景里。
1.3 网易杭研的考察偏好
具体到网易杭研这个岗位，我的感受是他们的笔试非常务实。题目范围很广，但每一题几乎都不白给，要么考你原理，要么考你实操，要么考你在极端场景下的判断力。
杭研这边的业务线大家应该都有耳闻，网易云音乐、网易严选、网易数帆这些产品都有大规模数据库使用场景，尤其是云音乐这种高并发读写、高峰时段流量波动极大的业务，对数据库团队的要求不只是"会装会配"，而是"能在极端压力下保证稳定"。所以笔试里出现性能优化类和故障恢复类的题目，我并不意外。
我建议后续要投这个岗位的同学，笔试前认真研究一下网易的业务形态，想一想这些业务对数据库的挑战在哪里。例如云音乐的评论、歌单、用户行为数据，哪些适合用MySQL，哪些适合用缓存，哪些需要走ES或者列存，这种"用数据库解决业务问题"的思路，恰恰是笔试想看到的。
2. 考点地图篇：笔试题型与知识板块全景拆解
2.1 客观题：细碎知识点地毯式扫描
笔试的第一板块是大量的客观题，有单选也有多选。这些题覆盖面很广，从SQL语法细节到InnoDB存储引擎的参数，再到各种日志的作用，可以说把数据库知识的边边角角都扫了一遍。
我回忆几个印象深刻的点供大家参考。
第一类是存储引擎相关。MyISAM和InnoDB的区别几乎是必考的。这题看似简单，但如果你想拿满分，需要答出：InnoDB支持事务、支持行级锁、支持外键、支持崩溃恢复，而MyISAM只支持表级锁、不支持事务、崩溃后恢复能力差。更细一点，还要知道InnoDB在MySQL 5.7以后支持全文索引，而MyISAM的索引和数据是分开存储的，InnoDB的数据和主键索引是存放在一起的。这些细节没有实际操作经验的话，很容易记混。
第二类是日志相关的题。redo log、undo log、binlog这三者有什么区别和联系，是DBA笔试的高频题。简单来说，redo log是InnoDB存储引擎层的物理日志，记录的是"数据页做了什么修改"，用于崩溃恢复；undo log是逻辑日志，用于事务回滚和多版本并发控制（MVCC）；binlog是MySQL Server层的逻辑日志，记录的是"执行的SQL语句或行变更"，用于主从复制和时间点恢复。三者的协作逻辑是：事务提交时，先写redo log（并保证落盘），再写binlog；崩溃恢复时，用redo log恢复数据页，用undo log回滚未提交的事务。
第三类是会考察MySQL参数层面的东西。比如max_connections、innodb_buffer_pool_size、slow_query_log这些参数是干嘛的，怎么调优。这类题没有运维经验的同学会比较吃亏，因为它们不是看书就能记住的，而是要在实际环境中观察过、调整过才会有直观感受。
2.2 SQL手写题：从增删改查到分析函数
客观题之后是SQL手写题。这部分和很多同学预想的不一样，它不只是简单的SELECT、INSERT、UPDATE、DELETE，而是大量考察了多表关联、子查询、聚合函数、窗口函数等进阶语法。
比如有一道题，给了两张业务表，一张是用户表，一张是订单表，要求统计出"每个用户的首次下单时间以及该用户累计下单金额排名前两名的订单"。这种题放到数据仓库笔试里也完全成立，但出现在DBA笔试里，说明他们对SQL基本功的要求是很高的。因为DBA日常工作中写SQL的机会确实不少，跑数据、排查问题、做数据订正，都要用SQL。
针对这类题，我最想提醒大家的是：窗口函数一定要熟练。ROW_NUMBER()、RANK()、DENSE_RANK()三者的区别必须刻在脑子里。ROW_NUMBER()是纯行号，排序值相同也会分配不同的序号；RANK()会为相同值分配相同序号，但后续序号会跳过，比如1、1、3；DENSE_RANK()则不会跳过，是1、1、2。很多场景下，取"每个分组Top N"这类需求用ROW_NUMBER()配PARTITION BY就能完美解决。
另外，分组统计时GROUP BY和HAVING的配合、WHERE与HAVING的执行顺序（WHERE先过滤行，HAVING后过滤分组）也是高频考点。还有各种JOIN的区别，特别是LEFT JOIN和INNER JOIN在数据匹配上的语义差异，稍不留神就会写错。
2.3 设计题：表设计、索引设计与反范式
笔试里还有一部分是数据库设计题，给定一个业务场景，要求你设计表结构并给出索引方案。
这类题考的不只是会不会建表，而是有没有工程经验。举个例子，如果场景是一个社交App的好友关系表，你需要考虑：是用自增主键还是业务主键？好友关系是单向关注还是双向好友？查询最频繁的是"我关注了谁"还是"谁关注了我"？这两个查询方向是否需要分别建索引？为了满足互相关注的查询，是否可以考虑冗余存储？
我在设计题上踩过的一个坑是：一开始把表设计得过度范式化，导致查询的时候需要关联五六张表。后来复盘才意识到，互联网业务中，大部分场景是读多写少，为了查询性能可以在一定程度上做反范式设计，比如冗余一些字段、预计算一些统计值。笔试中不会有人告诉你应该在三范式和查询性能之间怎么取舍，但阅卷人一定能看出来你有没有这种平衡意识。
索引设计这里有一个必须要掌握的面试/笔试考点：联合索引的最左前缀原则。建一个(a, b, c)联合索引，查询条件如果只包含b和c，那这个索引是走不上的；如果包含a和b，则可以走索引。还有覆盖索引的概念，如果查询列都能在索引中找到，就无需回表，性能会高很多。设计题里，合理使用联合索引和覆盖索引，往往是拉开分数差距的关键。
3. 底层原理篇：事务、锁与索引的"必考铁三角"
3.1 InnoDB索引：为什么是B+树而不是别的树
数据库笔试基本绕不开索引这个话题，而索引题的核心又是：InnoDB为什么用B+树？
这题看似基础，但想答好需要同时理解两层逻辑。第一层是：B+树相比其他数据结构，在数据库场景里有什么优势？第二层是：InnoDB具体是怎么用B+树的？
关于第一层，最常拿来对比的是B树和哈希索引。哈希索引的等值查询确实是O(1)级别，但无法支持范围查询和排序；B树的每个节点既保存索引键又保存数据，导致单个节点能存储的键数量更少，树更高，磁盘IO次数更多；而B+树的所有数据都在叶子节点，非叶子节点只存索引键，节点能容纳更多键，树更矮，同时叶子节点之间用链表相连，非常适合范围查询和顺序扫描。
关于第二层，InnoDB的每张表实际上就是一个以主键为索引键的B+树，叶子节点存储了整行数据，这叫聚簇索引。二级索引的叶子节点不存储完整行，而是存储主键值，因此通过二级索引查询时，通常还要回表到聚簇索引再查一次。如果你能让阅卷人感觉到你是从"树的样子"去理解索引的，而不是背概念，这道题基本就稳了。
3.2 事务隔离级别与MVCC
事务ACID属性是基础，但笔试真正拉开差距的，是对隔离级别和MVCC的深入理解。
标准SQL定义了四种隔离级别：读未提交、读已提交、可重复读、串行化。MySQL InnoDB的默认级别是可重复读（Repeatable Read）。为什么MySQL的默认隔离级别和其他数据库不一样，这一点是很多面试官喜欢追问的问题，笔试也常以判断题的形式出现。
答案在于：InnoDB通过MVCC（多版本并发控制）在可重复读级别下已经解决了部分幻读问题。MVCC的实现依赖三个核心东西：隐藏字段（DB_TRX_ID事务ID、DB_ROLL_PTR回滚指针）、undo log版本链、ReadView一致性视图。在可重复读级别下，事务在第一次查询时生成ReadView，后续复用这个ReadView，从而保证多次查询结果一致。而读已提交级别下，每次查询都会生成新的ReadView，所以会出现不可重复读。
笔试中关于MVCC还有一个高频陷阱题：快照读和当前读。普通的SELECT是快照读，不加锁，通过MVCC读历史版本；而SELECT ... FOR UPDATE、UPDATE、DELETE是当前读，读取最新版本并加锁。这个知识点如果没理解透，很容易在"哪些操作会加锁"这类多选题上出错。
3.3 死锁：从原理到排查
我在笔试中遇到一个很典型的场景题：两个事务分别执行两条UPDATE语句，更新顺序相反，导致死锁，问你怎么排查、怎么解决。
要答好这道题，先得把死锁的四个必要条件说清楚：互斥、持有并等待、不可剥夺、循环等待。然后结合InnoDB场景说明，行锁是互斥的，事务A持有行1的锁并等待行2，事务B持有行2的锁并等待行1，于是产生循环等待。
排查死锁的手段是：通过SHOW ENGINE INNODB STATUS查看LATEST DETECTED DEADLOCK部分，里面会记录死锁涉及的事务、加锁的SQL、持有的锁和等待的锁。模拟死锁场景，你还可以打开innodb_print_all_deadlocks参数，把每次死锁信息都打印到错误日志里，方便事后分析。
解决死锁的思路通常有几个方向：一是让所有事务按照相同的顺序访问资源，比如都先更新小ID的行再更新大ID的行；二是在高并发场景下减少大事务，缩短持锁时间；三是合理设计索引，尽量让锁定的行范围变小；四是在业务允许的情况下降低隔离级别。真题里最容易出的是第一种方向，也就是"统一加锁顺序"。
4. 故障实操篇：运维场景题里的互联网真实环境
4.1 慢查询：Explain的正确打开方式
在DBA的日常工作中，慢查询处理可能是最高频的工作之一。笔试中一定会出现慢查询优化的题目，而这类题的核心工具就是Explain。
给我印象最深的一道题是这样的：一条SQL执行非常慢，表里数据量在千万级，Explain结果中type列显示为ALL，也就是全表扫描，rows列预估扫描了上百万行，Extra列显示Using filesort。问题让你分析这条SQL慢的原因，并给出优化方案。
这种题的解题步骤其实非常固定。先看type，如果是ALL说明没走索引或索引失效；然后看Extra，如果出现Using filesort说明排序无法用到索引，MySQL需要额外排序；再看key列是不是为NULL。
至于索引失效的场景，笔试里也常考，包括：对索引列使用函数或运算，隐式类型转换，LIKE以通配符开头，OR连接非索引列条件等。比如WHERE DATE(create_time) = '2023-01-01'这种写法，即使create_time上有索引，因为用了DATE函数，索引也走不了，正确的写法是WHERE create_time >= '2023-01-01 00:00:00' AND create_time < '2023-01-02 00:00:00'。
4.2 在线变更表结构的学问
热搜词里有一个词出现了很多次：mysql数据库修改结构。这确实是DBA笔试里的一个知识点，而且实际工作中也极容易踩坑。
在很多同学的认知里，ALTER TABLE加个列不是很简单吗？但在千万级甚至亿级数据量的表上，直接执行ALTER TABLE ADD COLUMN在MySQL 5.7及之前的版本中通常要拷贝全表数据，期间会加MDL锁，阻塞读写。如果你的表是线上正在服务的表，那这波操作基本等于事故。
解法有几个方向，笔试里能答出两三个就算不错。第一个是使用gh-ost或者pt-online-schema-change这类工具做在线DDL变更，原理是通过触发器或Binlog同步数据到临时表，完成后原子切换表名。第二个是MySQL 8.0支持了INSTANT算法，对某些操作可以立即完成，比如在表末尾加列。第三个是错峰执行，在业务低峰期进行变更。
笔试中如果遇到这种题，记得把思路往"减少对业务的影响"上靠——是先变更从库，再切换主备，再变更主库？还是用工具在线操作？这两种方案分别有什么利弊？能答出这个层面，阅卷人就知道你真的考虑过线上环境的约束。
4.3 主从延迟与数据一致性
主从复制几乎是每个互联网公司数据库架构的标配，笔试中相关题目必考。常见的问题是：主从延迟产生的原因是什么？如何监控和处理？
主从延迟的本质是，从库重放主库Binlog的速度跟不上主库写入的速度。常见原因包括：从库硬件性能比主库差，大事务在主库执行一次而在从库也要重放一次，从库上有查询压力，或者主库是并发写入而从库是单线程/多线程复制但并行度不够。
笔试如果问你怎么解决，可以从这几个角度回答：一是硬件层面，从库规格不低于主库；二是从库开启并行复制（MTS，Multi-Threaded Slave），MySQL 5.7以后支持基于LOGICAL_CLOCK的并行复制，8.0还在优化；三是业务层面，拆分大事务，避免一次性更新上百万行；四是读流量治理，从库只承接可以容忍延迟的读请求，关键实时性要求高的读走主库。
再往后延伸一点，还有半同步复制（Semisynchronous Replication）的概念，主库要等至少一个从库确认收到Binlog才返回事务提交成功，以此降低数据丢失风险。还有组复制（Group Replication）和MGR架构，如果笔试里提到了"数据一致性"和"高可用"，这些概念可以一并带出。
4.4 热点词背后的真实考点：审计、索引争用与连接池
热搜词里有几个词非常值得玩味，比如"数据库开启审计 引起索引争用"和"mysql的数据库连接池"。这些几乎都是实际运维中才会遇到的问题，也侧面说明网易这类公司笔试的出题方向。
先说审计与索引争用。数据库开启审计功能后，每一次SQL执行都会写入审计日志，高并发场景下审计日志的写入会产生严重的锁竞争和IO开销，甚至引起BP（Buffer Pool）和索引页的争用。这类题考的是：你是否知道数据库审计是有代价的，你能否在合规需求和性能冲击之间做权衡。答题时可以提到审计策略要按需开启，尽量只审计关键表和关键操作，或者使用专门的审计插件/独立的审计日志存储。
再说连接池。笔试中会面到HikariCP、Druid、C3P0这些连接池的对比，以及连接池参数怎么设置。核心要理解：连接池不是越大越好。连接数过高会导致数据库端线程切换开销增加、上下文切换严重，反而降低吞吐。推荐的做法是压测确定最佳值，通常中小型应用8~16个连接就够，核心高并发应用也是几十到上百的量级，而不是几千。Druid在国产技术栈里非常流行，笔试里如果提到阿里的技术栈，大概率会问到Druid。
5. 边界扩展篇：国产数据库与新趋势考点
5.1 国产数据库走近校招笔试题
近几年国产数据库的势头大家有目共睹。热搜词里出现的达梦数据库、人大金仓、GaussDB、OceanBase、TiDB，其实都是国产数据库的代表。笔试里虽然不会让你写出某种国产数据库的全部语法，但很可能会以选择题或简答题的形式，考察你对国产数据库发展趋势的基本了解。
以达梦数据库为例，它兼容Oracle的很多特性，语法也大量兼容Oracle，因此学习过Oracle的人上手达梦会非常快。人大金仓（KingbaseES）则更偏向PostgreSQL生态。GaussDB有分布式版本和集中式版本，华为系产品周边经常出现。OceanBase是蚂蚁集团开源的分布式关系数据库，TiDB则是PingCAP开源的分布式NewSQL数据库。
如果你准备的是校招笔试，我建议至少要了解：国产数据库和MySQL/Oracle的兼容性差异、分布式数据库的基本架构（如TiDB的TiDB Server、PD、TiKV三层架构）、以及它们解决的典型痛点（如水平扩展、高可用、国产化替代）。这些知识在笔试中出现并不突兀，反而能体现出你对数据库行业趋势的敏感度。
5.2 向量数据库与时序数据库：不止是"关系型"
热搜词里有不少新方向，比如向量数据库、doris数据库、时序数据库的数据库结构设计。这其实透露了一个信号：现代DBA的知识边界，早就超出了MySQL/Oracle的范围。
向量数据库是这一两年的热点，核心解决的是AI场景下的相似向量检索问题，比如文本Embedding的相似度搜索、图片特征检索。代表产品有Milvus、FAISS（严格来说是向量索引库）、Qdrant等。如果笔试中问到向量数据库，大概率是考察你是否了解它在RAG（检索增强生成）或推荐系统中的应用，以及向量索引的基本思路（比如HNSW、IVF这类近似最近邻搜索算法）。
时序数据库则是另一个方向，代表产品有InfluxDB、TDengine、Prometheus（底层TSDB）、VictoriaMetrics等。时序数据库的核心特点是高写入吞吐、按时间维度聚合查询、数据生命周期管理。如果笔试中让你设计一个时序库的表结构，你至少应该想到：时间戳作为分区字段、设备ID/标签作为Tag、指标值作为Field、按时间保留策略做数据压缩。
Doris则是现在非常火的国产分析型MPP数据库，主要用于OLAP场景。如果笔试里提到Doris，考察点大概率在它的架构（FE和BE节点）、数据模型（Unique模型、Aggregate模型、Duplicate模型）、以及和MySQL生态的兼容性。
把这些扩展知识放进来，不是说让你每个方向都精通，而是想提醒大家：数据库管理工程师这个岗位的笔试范围越来越宽。你真正需要具备的，是"自顶向下的通识"和"自底向上的原理"。
5.3 笔试之后：从校招到DBA的成长路径
走到这一步，不管笔试结果如何，我已经把数据库管理工程师这个岗位的考察逻辑想得非常清楚了。笔试只是第一关，但它的指向性极其明确：你想做数据库方向，就要有"管理一个甚至一群数据库"的视角。
从准备笔试到后续面试，我的建议是建立一个自己的"数据库知识树"。树干是关系型数据库的核心机制——存储引擎、事务、锁、索引、日志、复制。树枝是不同类型的数据库产品——MySQL、PostgreSQL、Oracle、Redis、ES、TiDB、OceanBase、ClickHouse，每种都有自己的适用场景。树叶是具体的技术细节——参数配置、慢查询优化、备份恢复、监控告警、高可用架构。
具体到面试准备，我复盘后认为这几个方面值得重点投入：
第一，把MySQL源码级别的热点机制看透一轮。虽然校招生不要求有源码贡献经验，但如果你能讲清楚一条SELECT语句从客户端到服务端再到存储引擎的完整执行流程，讲清楚一条UPDATE语句在InnoDB中经历了哪些日志和缓冲区的交互，面试官会觉得你的底子很扎实。
第二，亲手做几次故障演练。自己在本地搭一套MySQL主从环境，把主库的Binlog模拟误删数据后的恢复过程跑一遍，把慢查询日志调出来分析一遍，把连接数打爆再排查一遍。没有亲手做过这些操作，面试时说到"故障排查"心里是虚的。
第三，阅读大厂的数据库实践总结。像网易云音乐、美团、阿里云、字节跳动的数据库团队都有不少对外分享，从真实案例中能学到很多笔试和面试中不会直接出现，但实际很容易踩坑的细节。
我个人在准备这场笔试的过程中，最大的收获其实不是背下了多少知识点，而是被迫建立了一个"全局视角"。以前写业务代码，数据库就是一个连接串；现在看数据库，我会想它是如何在一台台服务器上组织数据、管理并发、保证一致、扛住流量的。这个转变，比拿到任何一个offer都值。
如果你正在准备数据库管理工程师的校招，我想说：不要被那些海量的知识点吓到，也不要只盯着一本《高性能MySQL》死磕。把笔试当作一次"数据库体检"，它会诚实地告诉你，你在哪个层面还欠着火候。补上了，你就离这个岗位上岗更近了一步。
