1. 从这份笔试卷看网易在找什么样的数据库运维2018年网易校招数据库运维工程师BJ的笔试卷到现在还有人在找、在刷本身就说明了一个问题这份卷子出的有水平。网易不是第一次做校招数据库运维这个岗位也不是什么冷门方向但能把笔试题目出到让科班出身的人觉得扎实、让半路出家的人觉得有差距的程度并不多见。我当时拿到这份卷子的时候第一反应是这不像是一份运维岗的卷子因为它几乎覆盖了一个合格DBA需要具备的全部硬技能SQL功底、MySQL原理、Linux操作、网络排查、故障分析甚至还有一部分工程思维。你光会装个MySQL、会看个慢查询日志在这份卷子面前是撑不住的。它考的不是你背了多少命令而是你有没有在真实环境里踩过坑、有没有把数据库的运行机制想明白。所以这篇博文我会从这份卷子出发拆解数据库运维校招笔试的核心考点、出题逻辑和备考方法。不管你是准备校招的学生还是刚转行进运维的新人又或者是想系统补一遍数据库基础的在职同学这篇文章都会给你一个足够清晰的参考框架。我自己做了多年数据库运维也帮公司带过几届校招生站在出题人和面试官的角度把这些年的经验一起揉进来讲希望能帮你少走点弯路。1.1 笔试考察的三大维度一份有区分度的笔试卷一定不是靠题目难来刷人的而是靠知识点交叉来刷人的。网易这份卷子给我最深的感受就是它把基础理论工程能力系统思维三个维度揉在了一起。基础理论维度考的是数据库原理。索引的数据结构、事务的隔离级别、锁的兼容矩阵、日志的写入时机这些东西看起来是教科书上的老知识点但如果你只是背过概念没有动手实践过遇到具体的场景题会直接懵。比如它给你一个执行计划问你为什么这个SQL走了全表扫描而不是索引这种题光靠背索引失效的几条规则是答不全面的你得知道优化器是怎么估算行数的、回表的代价怎么算。工程能力维度考的是你拿到一台机器、一个故障能不能快速定位。这个部分通常不会直接说请写出排查步骤而是给你一个业务现象比如线上数据库CPU飙到100%连接数暴涨请你分析可能的原因并给出处理思路。这种题没有标准答案但答得好不好一眼就能看出来。见过真实故障的人会从连接数、慢查询、锁等待、磁盘IO几个方向同时排查没经验的人只会说重启一下试试。系统思维维度考的是你能不能站在整体架构的角度看问题。数据库不是孤立存在的它上面有业务、下面有操作系统、外面有网络任何一环出问题都会表现为数据库出问题了。所以网易这种大厂很看重你懂不懂Linux、懂不懂TCP/IP、懂不懂分布式系统的基本概念。这也是为什么这份卷子里会出现不少非数据库本身的题目。1.2 为什么大厂如此看重这些基础能力有人可能会问做运维不就是装环境、做备份、处理报警吗为什么要考这么多原理说实话如果你只想做一个操作型的运维确实不需要懂太多原理跟着文档敲命令也够用。但网易这种体量的公司数据库实例数以千计承载着游戏、邮箱、云音乐这些核心业务任何一次数据库抖动都可能是大事故。这种环境下运维不可能等故障发生后再慢慢翻文档必须对底层原理足够熟悉才能在几分钟内判断出问题的方向。再说直白一点基础决定上限。你是背过命令的人还是理解原理的人面试官跟你聊十分钟就能看出来。笔试只是第一道筛子它不是为了筛掉谁而是为了把那些连基础都不扎实的人提前拦下来免得浪费后面的面试时间。我自己带校招生的时候也明显感觉到在学校做过课程设计、自己折腾过MySQL主从、看过官方文档的人入职后的成长速度就是比只刷面经的人快。因为知识体系是活的遇到问题能举一反三。1.3 2018年的卷子放到今天还有没有参考价值这是一定要说清楚的虽然卷子是2018年的但它的参考价值到今天一点没减。数据库运维的核心知识栈这么多年并没有发生颠覆性的变化。MySQL还是那个MySQL索引还是B树事务还是ACID主从复制还是基于binlog。变化的是工具链和架构形态——云数据库更普及了、Kubernetes成了标配、国产数据库开始进入生产环境——但底层原理是相通的。所以我建议拿到这份卷子不要把它当成过期真题来背而是把它当成一份知识地图顺着它去补齐自己的短板。你会发现在准备这些考点的过程中顺带就把今天面试中高频考察的能力覆盖了。这篇文章后半部分我也会把一些2018年没考、但现在校招面试中越来越常见的方向比如国产数据库、分布式数据库、向量数据库一并整理出来帮你把这张地图延展到当下。2. 核心考点拆解数据库原理与MySQL进阶考察重点这一章我们来啃最硬的部分。不管网易这份卷子的具体题目怎么变数据库原理和MySQL进阶知识一定是占分最大、区分度最高的板块。我按知识群来拆每一个都讲清楚考什么、为什么考、怎么答才能拿高分。2.1 索引与执行计划最常考察的知识点群索引这块几乎是必考的而且考点非常集中。最常出现的是这几类题型给你一条SQL让你分析它能不能走索引给你一个表结构让你设计索引给你两个执行计划让你判断哪个更优并说明理由。要答好这类题你脑子里的知识结构应该是这样的索引底层的B树结构决定了它能支持范围查询和排序聚簇索引的叶子节点存的是整行数据二级索引的叶子节点存的是主键值所以走二级索引通常需要回表覆盖索引可以让查询不用回表性能高一大截联合索引遵循最左前缀原则这些是基础中的基础。但光知道这些还不够你还需要理解优化器的行为。比如有一个常见考题一个表上有联合索引(a, b)查询条件是where a 1 and c 2这时候索引能不能用到能用到但只用到索引的前缀ac这个条件需要回表之后才能过滤。如果你在回答里说索引失效了那这道题你就凉了。优化器没你想象的那么笨只要前置列能定位它就会用索引去缩小扫描范围只不过后续的过滤确实走不了索引而已。再比如索引失效的经典场景在索引列上做函数运算where DATE(create_time) 2024-01-01、隐式类型转换where mobile 13800138000但mobile是varchar、like %abc这种前导模糊匹配。这些场景不是概念上记一下就行你要能解释为什么失效——因为函数运算和类型转换会让索引列的值在比较前就被修改B树的排序结构就派不上用场了like %abc没法用索引是因为B树的叶子节点只支持前缀匹配。执行计划这块重点是看type列。从好到差依次是system、const、eq_ref、ref、range、index、ALL。校招笔试常考的是让你判断一个查询的type是ref还是range然后问你为什么。其实ref和range的区别很简单ref是等值匹配返回多行range是范围扫描但判断的时候要看条件形式比如where a 1是ref前提是有索引where a 1 and a 10是range。如果你能顺带提一嘴 Extra 列里的Using index覆盖索引、Using temporary用到临时表、Using filesort文件排序那就说明你是真看过执行计划不是背答案。提示答索引相关题目时先画表结构再分析尤其是说不准的时候把这张表有几个索引、每个索引包含哪些列先列出来再逐条分析。这样回答逻辑清晰判卷人一眼就能看到你的思路。2.2 事务隔离级别与锁死锁分析的经典套路事务和锁是数据库运维笔试的另一座高山也是实际工作中最容易出事故的地方。网易的卷子里通常会出现这类题目给你两个并发事务的操作序列问你最终是什么结果或者问你会不会死锁。事务部分ACID四个特性的定义大家都会背关键是隔离级别。MySQL InnoDB默认是REPEATABLE READ这个要知道但更重要的是理解MVCC多版本并发控制。MVCC解决的问题是读写不阻塞读操作通过快照读拿到历史版本写操作通过当前读拿到最新数据。这里就有个经典的坑快照读和当前读不是一回事在REPEATABLE READ下普通的SELECT是快照读SELECT ... FOR UPDATE、UPDATE、DELETE是当前读。这道题如果考你一个事务里先普通SELECT再UPDATE别的事务插入了一条符合条件的数据会发生什么你要能说出普通SELECT看不到新插入的数据但UPDATE会把新插入的行也锁住并更新掉这就是幻读在当前读下的一种体现。锁这块InnoDB的锁有三种基本模式共享锁S、排他锁X和三种基本类型记录锁Record Lock、间隙锁Gap Lock、临键锁Next-Key Lock。间隙锁和临键锁是InnoDB在REPEATABLE READ下解决幻读的关键但也是死锁的高发原因。笔试最常见的死锁题是这样的事务A先UPDATE table SET x 1 WHERE id 10事务B先UPDATE table SET x 2 WHERE id 20然后事务A再UPDATE table SET x 3 WHERE id 20事务B再UPDATE table SET x 4 WHERE id 10。此时事务A持有id10的行锁等id20的行锁事务B持有id20的行锁等id10的行锁互不相让死锁。这个例子虽然简单但你要能从持有和等待两个维度画一个锁等待图这才是拿分的关键。排查死锁的经验也要储备。实际工作中死锁发生时第一步是SHOW ENGINE INNODB STATUS看LATEST DETECTED DEADLOCK部分里面会明确告诉你两个事务分别在什么位置持有什么锁、等待什么锁。笔试里如果考你排查思路你能说出这个命令并解释如何解读输出就已经赢了大多数人。实操心得死锁分析不要只在纸面上推强烈建议自己开两个MySQL会话手动制造一次死锁然后看SHOW ENGINE INNODB STATUS的实际输出。你亲手触发过一次对锁兼容矩阵、锁等待超时参数innodb_lock_wait_timeout的理解会完全不一样。2.3 日志体系redo、undo、binlog与主从复制原理日志体系是数据库运维笔试的另一大考点也是区分会用MySQL和懂MySQL的分水岭。InnoDB的日志体系三大件redo log、undo log、binlog各司其职缺一不可。redo log是InnoDB存储引擎层的日志记录的是物理修改哪个数据页的哪个位置被改成了什么它的作用是崩溃恢复。因为数据库不会每次修改都把数据页刷到磁盘而是先写redo log到磁盘再异步刷数据页这个技术叫WALWrite-Ahead Logging先写日志再写数据。如果数据库崩溃了数据页还没来得及刷盘重启后可以用redo log重放来恢复。undo log记录的是逻辑修改的反操作用于事务回滚和MVCC快照读。每个事务修改数据之前会先把旧值写到undo log。如果事务回滚就用undo log把数据还原如果其他事务需要读旧版本的数据也是通过undo log的版本链去追溯。binlog是MySQL Server层的日志记录的是逻辑SQL或者行级别的变更它的主要用途是主从复制和数据恢复。这里有个经典考点为什么需要两阶段提交因为redo log和binlog是两个独立的日志如果不做协调可能会出现redo log写成功了但binlog没写成功的情况导致主从数据不一致。解决办法就是两阶段提交prepare和commit两个阶段先写redo log并标记为prepare再写binlog最后把redo log更新为commit状态。这个流程能保证主库和从库的数据最终一致。主从复制这块流程要能讲清楚主库写入binlog从库的IO线程把binlog拉过来写到本地的relay log从库的SQL线程再读取relay log并回放。异步复制有延迟问题所以有了半同步复制主库要等至少一个从库确认收到binlog才提交和GTID复制用全局事务ID来避免手动指定binlog文件和位置复制更可靠。笔试里如果考你主从延迟怎么解决方向主要有这几个检查从库硬件性能、检查大事务、优化单线程回放或启用并行复制、避免从库做过多查询压力。2.4 备份恢复与高可用试卷里最送分也最送命的部分备份恢复和高可用是数据库运维日常工作中最核心的职责之一笔试自然不会回避。送分是因为方向明确送命是因为很多人只会喊口号说不清楚具体怎么做。先说备份策略。逻辑备份工具是mysqldump物理备份工具是XtraBackup现在叫Percona XtraBackup。笔试爱问的是一张200G的表用mysqldump备份需要多长时间有哪些坑答案里要包含mysqldump在备份时默认会加全局读锁以保证一致性对大表来说这个锁的持有时间可能很长影响线上业务所以大表的物理备份通常用XtraBackup它可以不阻塞业务基于InnoDB的崩溃恢复机制来做一致性备份。如果只能选一个方案我会说小库用mysqldump大库用XtraBackup这个判断本身就是面试官想听的。恢复这块必须讲清楚RPO和RTO的概念。RPO是数据丢失容忍度RTO是恢复时间目标。做数据库运维任何备份方案都要围绕这两个指标来设计。如果你能说出全量备份binlog增量备份是常规组合——每天凌晨全量期间用binlog做增量恢复时先恢复全量再用binlog回放到任意时间点——那这道题基本就稳了。高可用方案也是常考的。MySQL常规高可用组合有主从复制MHA、半同步复制Keepalived、Orchestrator、以及云上的RDS高可用。校招笔试不会让你设计太复杂的架构但会让你解释主从切换的过程如何判断主库不可用、如何选择一个从库提升为主库、如何处理原主库恢复后的数据同步这几个环节能答出逻辑就已经达到要求了。实际环境中还有一个容易被忽略的细节主从切换后应用侧的连接池要能自动感知新主库的地址不然数据库切了但应用还在连旧地址等于白切。3. Linux与网络基础笔试里那些看似送分的题目很多准备数据库运维岗位的同学把时间全花在数据库原理上对Linux和网络基础比较轻视觉得不是DBA吗怎么还考操作系统。但据我观察网易这份卷子以及其他大厂的校招笔试卷Linux和网络部分往往承担着刷掉眼高手低型选手的功能。表面上是让你写几个命令、分析几个网络现象其实考的是你在真实环境里有没有动过手。3.1 必考的Linux命令与系统排查类题目数据库运维的基本功一半在数据库一半在Linux。你维护的MySQL实例跑在Linux上CPU、内存、磁盘、文件句柄任何一个资源出问题都会表现为数据库异常。所以笔试里出现Linux命令题一点都不奇怪而且通常还会和数据库场景结合。常考的命令分几类第一类是系统资源查看。top看CPU和内存free -h看内存详情df -h和iostat看磁盘空间和IOss -tnlp或netstat -tnlp看端口监听情况。光会命令不行还要会解读输出。比如top里面load average是1.5、2.0、3.0这三个数值分别代表1分钟、5分钟、15分钟的平均负载如果单核CPU的load超过4说明系统已经严重过载了这时候数据库响应慢就不奇怪。还有iostat里的%util如果接近100%说明磁盘IO已经打满了慢查询和锁等待大概率都跟它有关。第二类是日志和文件操作。查日志是运维的基本功grep、awk、sed这三个命令必须熟练。比如线上有大量慢查询你需要在慢查询日志里统计出现次数最多的前10条SQL一个命令就能搞定grep -E Query_time slow.log | awk {print $3} | sort | uniq -c | sort -rn | head -10。写不出来也没关系但思路要有先筛选、再提取、再排序、再取前N条。这种题不是考你背命令是考你面对一个具体问题能不能用工具解出来。第三类是进程与服务管理。ps aux查进程kill优雅终止先kill -15不行再kill -9systemctl status mysqld查服务状态。笔试可能给你一个场景比如MySQL进程还在但端口连不上让你排查。第一反应应该是检查进程是否真的存活、端口是否真的在监听注意ss -tnlp | grep 3306没有输出和ps aux | grep mysqld有输出并不矛盾可能进程僵死或者端口被占用这些都是实际中会踩的坑。注意回答命令类题目时别只写一条命令要把先做什么、再做什么、每一步看什么写清楚。比如查端口我会先ss -tnlp | grep 3306确认监听状态再telnet 127.0.0.1 3306或nc -zv 127.0.0.1 3306确认是否能建立连接最后再检查防火墙规则iptables/firewalld和SELinux状态。这种递进式的排查思路比单纯列命令更能拿分。3.2 网络基础从三次握手到数据库连接超时数据库运维离不开网络。你排查任何连接类故障最后几乎都会追问到网络层面。校招笔试里网络题不会考得太深但TCP三次握手、四次挥手、TIME_WAIT、连接超时这些概念几乎年年出现。先讲一个最经典的场景题线上应用报数据库连接超时你怎么排查这个问题我见过很多面试者只写一句检查网络通不通然后就没下文了。实际上一个完整的排查链条应该是这样的先确认应用到数据库的网络连通性用ping测ICMP、用telnet 数据库IP 端口测TCP连接然后看数据库侧的端口监听ss -tnlp再查数据库的最大连接数是否打满show variables like max_connections和show status like Threads_connected如果连接数没满还要看是不是连接被防火墙拦了或者数据库负载太高导致accept队列打满。TCP握手这块有个高频知识点为什么会有TIME_WAIT状态因为主动关闭连接的一方在发送最后一个ACK后要等待2MSL最大报文段生存时间才能释放连接目的是确保最后的ACK能被对方收到如果丢了可以重发。在连接频繁建立和关闭的场景下TIME_WAIT连接过多会造成端口资源耗尽出现Cannot assign requested address错误这也是数据库连接池偶发连接失败的常见原因之一。DNS也是容易被忽略的地方。应用连接数据库如果用的是域名而不是IP每次建连都要做一次DNS解析如果DNS解析慢或者有超时表现也是连接超时。排查时可以nslookup或dig看解析耗时也可以建议应用侧做DNS缓存。这个考点通常不会单独出题但放在故障排查综合题里是很漂亮的加分点。3.3 Shell脚本与自动化运维工程化的敲门砖说实话校招笔试里直接考Shell脚本写的题目不算多但网易这种级别的公司很有可能会在笔试或面试里让你写一段处理日志的脚本或者让你说说如何批量检查100台机器上MySQL实例的运行状态。这个考点的本质不是考语法是考自动化意识。你做运维面对的是一堆机器和一堆实例如果不能把重复操作自动化效率和出错率都没法看。所以哪怕笔试没考到我也建议你在备考时认真练一练Shell脚本。一个比较典型的考察方向是日志分析。比如给你一个nginx访问日志让你统计出访问量最高的前10个IP。写成Shell就是awk {print $1} access.log | sort | uniq -c | sort -rn | head -10。如果条件换一下比如要统计某个时间段内的请求量就要用awk先过滤时间字段再按分钟或小时做聚合。另一个方向是批量操作比如写一个脚本SSH到多台机器执行同一个命令那就要用到for循环和远程执行参数。注意脚本里要考虑超时、失败重试、日志输出这些细节面试官看到你能想到这些说明你考虑过真实场景不是一个只会背语法的学生。实操心得Shell脚本容易出现本地没问题到生产环境就报错的情况很大原因是没做兼容处理。比如用#!/bin/bash指定解释器、检查关键变量是否为空、命令不存在时的fallback逻辑。还有一点写脚本时养成用set -euxo pipefail开头的好习惯至少要有set -e这样脚本出错时会立刻退出而不是继续往下跑导致更严重的问题。4. 如果重回考场答题策略与延伸学习建议这一章不说知识点了说点更实在的话拿到一份笔试卷怎么分配时间、怎么组织答案、怎么从真题延伸出一个完整的备考体系。我在一线做运维这么多年也帮公司筛过不少简历和笔试卷站在出题人的角度有一些心得体会想分享给你。4.1 笔试时间分配与答题思路数据库运维笔试卷通常是选择题、简答题、SQL题、场景分析题的组合。我建议的策略是选择题快速横扫不会的标记出来最后再回来蒙不要在单题上耗超过2分钟SQL题认真写这类题通常有明确的正确答案是送分题但也是最容易因为细节丢分的——表名写错、漏掉WHERE条件、忘记去重任何一个低级错误都会让你和后面的同学拉开差距简答题和场景题留够时间因为你不仅要写出结论还要能展示完整分析过程。答题思路上有一个关键技巧答案要有层次感。先用一句话给出结论再说依据和推理过程最后补一个边界条件或注意事项。举个例子题目问为什么这个SQL没用索引不要只写因为索引失效可以这样答结论是这个查询条件里对索引列做了函数运算依据是B树的叶子节点按原值排序函数运算后无法利用排序结构做快速查找建议改成WHERE create_time 2024-01-01 AND create_time 2024-01-02这种范围写法既能走索引又保持了语义。这种三段式回答判卷人扫描起来舒服你拿到分数的概率也高。4.2 从真题延伸到今天一份补充学习清单如果你不想只盯着这份2018年的卷子还想把知识版图扩展到今年校招面试的高频方向我把最近几年越来越重要的几个方向整理成了一张清单。第一个是国产数据库。达梦、人大金仓KingbaseES、GaussDB、OceanBase、TiDB这些名字在现在的运维招聘里出现的频率越来越高。很多国企和政企项目已经明确要求使用国产数据库厂商认证培训都排得很满。我建议你至少装一个达梦或者人大金仓的社区版跟着官方文档把安装、建库、迁移、备份走一遍。你会发现在Linux上的部署逻辑和MySQL很接近但很多细节不同比如语法兼容性、表空间管理、命令行工具提前摸过一遍面试时提到你会用过国产数据库是很明显的加分项。第二个是分布式数据库和云原生数据库。TiDB、OceanBase这种原生分布式数据库笔试可能不会深入考实现原理但你要知道它们和单机MySQL的本质区别分布式事务、自动分片、弹性扩缩容、多副本一致性。如果被问到什么场景适合用分布式数据库你的思路应该是从数据量、写入吞吐、扩展性、成本几个维度去分析而不是背一句分布式数据库很牛。云数据库比如阿里云RDS、腾讯云TDSQL也是同样的思路你要理解托管数据库和自建数据库的利弊。第三个是向量数据库。这个方向是最近两年才热起来的跟AI应用关系很大。面试官可能会问一句向量数据库和传统数据库有什么区别。你只需要讲清楚向量数据库存的是向量一组浮点数检索的方式是近似最近邻搜索比如HNSW算法典型场景是RAG、相似图片检索很多从MySQL、PostgreSQL扩展出来的向量能力也在快速发展。这块不需要深究算法但知道概念、知道实际应用场景已经能让你跟上行业节奏。第四个是数据库同步工具。现在很多公司的数据要从业务库同步到数仓、同步到异构数据库这一类工具如Canal、Debezium、DataX、Flink CDC在校招面试中的出现率越来越高。核心考点在于基于binlog的增量同步原理、全量同步与增量同步的衔接、同步延迟的监控与处理。理解了MySQL主从复制的原理后这些工具学起来会非常快。4.3 校招备考中容易踩的坑最后说说我在带校招生和看笔试答卷时最常看到的问题。这些都是真话你提前知道至少能避开一半的坑。第一个坑是只看不练。很多人复习数据库原理翻了一堆博客和面经觉得自己懂了结果一上手写SQL或者分析执行计划就露馅。我的建议是备考期间一定要动手搭一套环境MySQL装起来造几万条数据把索引、事务、日志、主从复制全部亲手过一遍。不需要很复杂的机器一台4G内存的虚拟机就够。纸上得来终觉浅这句话用在数据库技术上再合适不过。第二个坑是不注意版本差异。MySQL 5.7和MySQL 8.0在不少特性上差别很大比如8.0默认字符集变成了utf8mb4、取消了查询缓存、增加了窗口函数、binlog格式默认是ROW。笔试题目如果没说明版本你回答时可以用以MySQL 8.0为例来限定范围这样既显得严谨也避免因为版本问题被扣分。第三个坑是会做不会说。笔试是文字表达你写得出来不代表面试时你能说出来。建议在准备阶段每做完一个知识点尝试用自己的话复述一遍就当作在给一个完全不懂数据库的同事讲。如果你能讲到对方听懂那才算真的掌握了。这个能力在面试环节尤其重要因为面试官问的很多问题都是让你讲一下分析一下。5. 写在最后一份老运维的真实建议这篇文章从网易2018年的笔试卷出发把数据库运维校招笔试的核心考点、答题策略和延伸学习方向都过了一遍。说到底笔试只是你进入这个行业的第一道门它考察的永远不是你背诵的能力而是你有没有建立一套完整的知识体系、有没有动手实践的经验、有没有面对复杂问题时冷静分析的习惯。我见过太多同学把大量时间花在刷题上这是有必要的但不是全部。真正能让你从同龄人里脱颖而出的是你在准备过程中积累的对系统的理解、对故障的感知、对细节的执着。这些能力不是靠笔试题目本身获得的而是靠你一遍遍亲手操作、踩坑、复盘得来的。所以如果你现在正在准备校招我的建议是拿一份真题不要先看答案限时2小时认真做一遍然后对照答案解析把每个考点都标记出来再按这篇文章的思路把知识体系补齐。整个过程不要追求快要追求扎实。等你把MySQL装了一遍、把主从复制搭了一遍、把一次死锁亲手复现了一遍你会发现笔试和面试都只是水到渠成的事。最后再分享一个小技巧把每次做错的题、没答上来的知识点记到一个笔记里每周翻一遍。考前一周重点看这些笔记比再刷一遍完整题库有效得多。这个过程很枯燥但数据库运维这个行业本来就没那么多捷径可走。共勉。 数据库运维校招笔试核心考点与备考策略解析
1. 从这份笔试卷看网易在找什么样的数据库运维2018年网易校招数据库运维工程师BJ的笔试卷到现在还有人在找、在刷本身就说明了一个问题这份卷子出的有水平。网易不是第一次做校招数据库运维这个岗位也不是什么冷门方向但能把笔试题目出到让科班出身的人觉得扎实、让半路出家的人觉得有差距的程度并不多见。我当时拿到这份卷子的时候第一反应是这不像是一份运维岗的卷子因为它几乎覆盖了一个合格DBA需要具备的全部硬技能SQL功底、MySQL原理、Linux操作、网络排查、故障分析甚至还有一部分工程思维。你光会装个MySQL、会看个慢查询日志在这份卷子面前是撑不住的。它考的不是你背了多少命令而是你有没有在真实环境里踩过坑、有没有把数据库的运行机制想明白。所以这篇博文我会从这份卷子出发拆解数据库运维校招笔试的核心考点、出题逻辑和备考方法。不管你是准备校招的学生还是刚转行进运维的新人又或者是想系统补一遍数据库基础的在职同学这篇文章都会给你一个足够清晰的参考框架。我自己做了多年数据库运维也帮公司带过几届校招生站在出题人和面试官的角度把这些年的经验一起揉进来讲希望能帮你少走点弯路。1.1 笔试考察的三大维度一份有区分度的笔试卷一定不是靠题目难来刷人的而是靠知识点交叉来刷人的。网易这份卷子给我最深的感受就是它把基础理论工程能力系统思维三个维度揉在了一起。基础理论维度考的是数据库原理。索引的数据结构、事务的隔离级别、锁的兼容矩阵、日志的写入时机这些东西看起来是教科书上的老知识点但如果你只是背过概念没有动手实践过遇到具体的场景题会直接懵。比如它给你一个执行计划问你为什么这个SQL走了全表扫描而不是索引这种题光靠背索引失效的几条规则是答不全面的你得知道优化器是怎么估算行数的、回表的代价怎么算。工程能力维度考的是你拿到一台机器、一个故障能不能快速定位。这个部分通常不会直接说请写出排查步骤而是给你一个业务现象比如线上数据库CPU飙到100%连接数暴涨请你分析可能的原因并给出处理思路。这种题没有标准答案但答得好不好一眼就能看出来。见过真实故障的人会从连接数、慢查询、锁等待、磁盘IO几个方向同时排查没经验的人只会说重启一下试试。系统思维维度考的是你能不能站在整体架构的角度看问题。数据库不是孤立存在的它上面有业务、下面有操作系统、外面有网络任何一环出问题都会表现为数据库出问题了。所以网易这种大厂很看重你懂不懂Linux、懂不懂TCP/IP、懂不懂分布式系统的基本概念。这也是为什么这份卷子里会出现不少非数据库本身的题目。1.2 为什么大厂如此看重这些基础能力有人可能会问做运维不就是装环境、做备份、处理报警吗为什么要考这么多原理说实话如果你只想做一个操作型的运维确实不需要懂太多原理跟着文档敲命令也够用。但网易这种体量的公司数据库实例数以千计承载着游戏、邮箱、云音乐这些核心业务任何一次数据库抖动都可能是大事故。这种环境下运维不可能等故障发生后再慢慢翻文档必须对底层原理足够熟悉才能在几分钟内判断出问题的方向。再说直白一点基础决定上限。你是背过命令的人还是理解原理的人面试官跟你聊十分钟就能看出来。笔试只是第一道筛子它不是为了筛掉谁而是为了把那些连基础都不扎实的人提前拦下来免得浪费后面的面试时间。我自己带校招生的时候也明显感觉到在学校做过课程设计、自己折腾过MySQL主从、看过官方文档的人入职后的成长速度就是比只刷面经的人快。因为知识体系是活的遇到问题能举一反三。1.3 2018年的卷子放到今天还有没有参考价值这是一定要说清楚的虽然卷子是2018年的但它的参考价值到今天一点没减。数据库运维的核心知识栈这么多年并没有发生颠覆性的变化。MySQL还是那个MySQL索引还是B树事务还是ACID主从复制还是基于binlog。变化的是工具链和架构形态——云数据库更普及了、Kubernetes成了标配、国产数据库开始进入生产环境——但底层原理是相通的。所以我建议拿到这份卷子不要把它当成过期真题来背而是把它当成一份知识地图顺着它去补齐自己的短板。你会发现在准备这些考点的过程中顺带就把今天面试中高频考察的能力覆盖了。这篇文章后半部分我也会把一些2018年没考、但现在校招面试中越来越常见的方向比如国产数据库、分布式数据库、向量数据库一并整理出来帮你把这张地图延展到当下。2. 核心考点拆解数据库原理与MySQL进阶考察重点这一章我们来啃最硬的部分。不管网易这份卷子的具体题目怎么变数据库原理和MySQL进阶知识一定是占分最大、区分度最高的板块。我按知识群来拆每一个都讲清楚考什么、为什么考、怎么答才能拿高分。2.1 索引与执行计划最常考察的知识点群索引这块几乎是必考的而且考点非常集中。最常出现的是这几类题型给你一条SQL让你分析它能不能走索引给你一个表结构让你设计索引给你两个执行计划让你判断哪个更优并说明理由。要答好这类题你脑子里的知识结构应该是这样的索引底层的B树结构决定了它能支持范围查询和排序聚簇索引的叶子节点存的是整行数据二级索引的叶子节点存的是主键值所以走二级索引通常需要回表覆盖索引可以让查询不用回表性能高一大截联合索引遵循最左前缀原则这些是基础中的基础。但光知道这些还不够你还需要理解优化器的行为。比如有一个常见考题一个表上有联合索引(a, b)查询条件是where a 1 and c 2这时候索引能不能用到能用到但只用到索引的前缀ac这个条件需要回表之后才能过滤。如果你在回答里说索引失效了那这道题你就凉了。优化器没你想象的那么笨只要前置列能定位它就会用索引去缩小扫描范围只不过后续的过滤确实走不了索引而已。再比如索引失效的经典场景在索引列上做函数运算where DATE(create_time) 2024-01-01、隐式类型转换where mobile 13800138000但mobile是varchar、like %abc这种前导模糊匹配。这些场景不是概念上记一下就行你要能解释为什么失效——因为函数运算和类型转换会让索引列的值在比较前就被修改B树的排序结构就派不上用场了like %abc没法用索引是因为B树的叶子节点只支持前缀匹配。执行计划这块重点是看type列。从好到差依次是system、const、eq_ref、ref、range、index、ALL。校招笔试常考的是让你判断一个查询的type是ref还是range然后问你为什么。其实ref和range的区别很简单ref是等值匹配返回多行range是范围扫描但判断的时候要看条件形式比如where a 1是ref前提是有索引where a 1 and a 10是range。如果你能顺带提一嘴 Extra 列里的Using index覆盖索引、Using temporary用到临时表、Using filesort文件排序那就说明你是真看过执行计划不是背答案。提示答索引相关题目时先画表结构再分析尤其是说不准的时候把这张表有几个索引、每个索引包含哪些列先列出来再逐条分析。这样回答逻辑清晰判卷人一眼就能看到你的思路。2.2 事务隔离级别与锁死锁分析的经典套路事务和锁是数据库运维笔试的另一座高山也是实际工作中最容易出事故的地方。网易的卷子里通常会出现这类题目给你两个并发事务的操作序列问你最终是什么结果或者问你会不会死锁。事务部分ACID四个特性的定义大家都会背关键是隔离级别。MySQL InnoDB默认是REPEATABLE READ这个要知道但更重要的是理解MVCC多版本并发控制。MVCC解决的问题是读写不阻塞读操作通过快照读拿到历史版本写操作通过当前读拿到最新数据。这里就有个经典的坑快照读和当前读不是一回事在REPEATABLE READ下普通的SELECT是快照读SELECT ... FOR UPDATE、UPDATE、DELETE是当前读。这道题如果考你一个事务里先普通SELECT再UPDATE别的事务插入了一条符合条件的数据会发生什么你要能说出普通SELECT看不到新插入的数据但UPDATE会把新插入的行也锁住并更新掉这就是幻读在当前读下的一种体现。锁这块InnoDB的锁有三种基本模式共享锁S、排他锁X和三种基本类型记录锁Record Lock、间隙锁Gap Lock、临键锁Next-Key Lock。间隙锁和临键锁是InnoDB在REPEATABLE READ下解决幻读的关键但也是死锁的高发原因。笔试最常见的死锁题是这样的事务A先UPDATE table SET x 1 WHERE id 10事务B先UPDATE table SET x 2 WHERE id 20然后事务A再UPDATE table SET x 3 WHERE id 20事务B再UPDATE table SET x 4 WHERE id 10。此时事务A持有id10的行锁等id20的行锁事务B持有id20的行锁等id10的行锁互不相让死锁。这个例子虽然简单但你要能从持有和等待两个维度画一个锁等待图这才是拿分的关键。排查死锁的经验也要储备。实际工作中死锁发生时第一步是SHOW ENGINE INNODB STATUS看LATEST DETECTED DEADLOCK部分里面会明确告诉你两个事务分别在什么位置持有什么锁、等待什么锁。笔试里如果考你排查思路你能说出这个命令并解释如何解读输出就已经赢了大多数人。实操心得死锁分析不要只在纸面上推强烈建议自己开两个MySQL会话手动制造一次死锁然后看SHOW ENGINE INNODB STATUS的实际输出。你亲手触发过一次对锁兼容矩阵、锁等待超时参数innodb_lock_wait_timeout的理解会完全不一样。2.3 日志体系redo、undo、binlog与主从复制原理日志体系是数据库运维笔试的另一大考点也是区分会用MySQL和懂MySQL的分水岭。InnoDB的日志体系三大件redo log、undo log、binlog各司其职缺一不可。redo log是InnoDB存储引擎层的日志记录的是物理修改哪个数据页的哪个位置被改成了什么它的作用是崩溃恢复。因为数据库不会每次修改都把数据页刷到磁盘而是先写redo log到磁盘再异步刷数据页这个技术叫WALWrite-Ahead Logging先写日志再写数据。如果数据库崩溃了数据页还没来得及刷盘重启后可以用redo log重放来恢复。undo log记录的是逻辑修改的反操作用于事务回滚和MVCC快照读。每个事务修改数据之前会先把旧值写到undo log。如果事务回滚就用undo log把数据还原如果其他事务需要读旧版本的数据也是通过undo log的版本链去追溯。binlog是MySQL Server层的日志记录的是逻辑SQL或者行级别的变更它的主要用途是主从复制和数据恢复。这里有个经典考点为什么需要两阶段提交因为redo log和binlog是两个独立的日志如果不做协调可能会出现redo log写成功了但binlog没写成功的情况导致主从数据不一致。解决办法就是两阶段提交prepare和commit两个阶段先写redo log并标记为prepare再写binlog最后把redo log更新为commit状态。这个流程能保证主库和从库的数据最终一致。主从复制这块流程要能讲清楚主库写入binlog从库的IO线程把binlog拉过来写到本地的relay log从库的SQL线程再读取relay log并回放。异步复制有延迟问题所以有了半同步复制主库要等至少一个从库确认收到binlog才提交和GTID复制用全局事务ID来避免手动指定binlog文件和位置复制更可靠。笔试里如果考你主从延迟怎么解决方向主要有这几个检查从库硬件性能、检查大事务、优化单线程回放或启用并行复制、避免从库做过多查询压力。2.4 备份恢复与高可用试卷里最送分也最送命的部分备份恢复和高可用是数据库运维日常工作中最核心的职责之一笔试自然不会回避。送分是因为方向明确送命是因为很多人只会喊口号说不清楚具体怎么做。先说备份策略。逻辑备份工具是mysqldump物理备份工具是XtraBackup现在叫Percona XtraBackup。笔试爱问的是一张200G的表用mysqldump备份需要多长时间有哪些坑答案里要包含mysqldump在备份时默认会加全局读锁以保证一致性对大表来说这个锁的持有时间可能很长影响线上业务所以大表的物理备份通常用XtraBackup它可以不阻塞业务基于InnoDB的崩溃恢复机制来做一致性备份。如果只能选一个方案我会说小库用mysqldump大库用XtraBackup这个判断本身就是面试官想听的。恢复这块必须讲清楚RPO和RTO的概念。RPO是数据丢失容忍度RTO是恢复时间目标。做数据库运维任何备份方案都要围绕这两个指标来设计。如果你能说出全量备份binlog增量备份是常规组合——每天凌晨全量期间用binlog做增量恢复时先恢复全量再用binlog回放到任意时间点——那这道题基本就稳了。高可用方案也是常考的。MySQL常规高可用组合有主从复制MHA、半同步复制Keepalived、Orchestrator、以及云上的RDS高可用。校招笔试不会让你设计太复杂的架构但会让你解释主从切换的过程如何判断主库不可用、如何选择一个从库提升为主库、如何处理原主库恢复后的数据同步这几个环节能答出逻辑就已经达到要求了。实际环境中还有一个容易被忽略的细节主从切换后应用侧的连接池要能自动感知新主库的地址不然数据库切了但应用还在连旧地址等于白切。3. Linux与网络基础笔试里那些看似送分的题目很多准备数据库运维岗位的同学把时间全花在数据库原理上对Linux和网络基础比较轻视觉得不是DBA吗怎么还考操作系统。但据我观察网易这份卷子以及其他大厂的校招笔试卷Linux和网络部分往往承担着刷掉眼高手低型选手的功能。表面上是让你写几个命令、分析几个网络现象其实考的是你在真实环境里有没有动过手。3.1 必考的Linux命令与系统排查类题目数据库运维的基本功一半在数据库一半在Linux。你维护的MySQL实例跑在Linux上CPU、内存、磁盘、文件句柄任何一个资源出问题都会表现为数据库异常。所以笔试里出现Linux命令题一点都不奇怪而且通常还会和数据库场景结合。常考的命令分几类第一类是系统资源查看。top看CPU和内存free -h看内存详情df -h和iostat看磁盘空间和IOss -tnlp或netstat -tnlp看端口监听情况。光会命令不行还要会解读输出。比如top里面load average是1.5、2.0、3.0这三个数值分别代表1分钟、5分钟、15分钟的平均负载如果单核CPU的load超过4说明系统已经严重过载了这时候数据库响应慢就不奇怪。还有iostat里的%util如果接近100%说明磁盘IO已经打满了慢查询和锁等待大概率都跟它有关。第二类是日志和文件操作。查日志是运维的基本功grep、awk、sed这三个命令必须熟练。比如线上有大量慢查询你需要在慢查询日志里统计出现次数最多的前10条SQL一个命令就能搞定grep -E Query_time slow.log | awk {print $3} | sort | uniq -c | sort -rn | head -10。写不出来也没关系但思路要有先筛选、再提取、再排序、再取前N条。这种题不是考你背命令是考你面对一个具体问题能不能用工具解出来。第三类是进程与服务管理。ps aux查进程kill优雅终止先kill -15不行再kill -9systemctl status mysqld查服务状态。笔试可能给你一个场景比如MySQL进程还在但端口连不上让你排查。第一反应应该是检查进程是否真的存活、端口是否真的在监听注意ss -tnlp | grep 3306没有输出和ps aux | grep mysqld有输出并不矛盾可能进程僵死或者端口被占用这些都是实际中会踩的坑。注意回答命令类题目时别只写一条命令要把先做什么、再做什么、每一步看什么写清楚。比如查端口我会先ss -tnlp | grep 3306确认监听状态再telnet 127.0.0.1 3306或nc -zv 127.0.0.1 3306确认是否能建立连接最后再检查防火墙规则iptables/firewalld和SELinux状态。这种递进式的排查思路比单纯列命令更能拿分。3.2 网络基础从三次握手到数据库连接超时数据库运维离不开网络。你排查任何连接类故障最后几乎都会追问到网络层面。校招笔试里网络题不会考得太深但TCP三次握手、四次挥手、TIME_WAIT、连接超时这些概念几乎年年出现。先讲一个最经典的场景题线上应用报数据库连接超时你怎么排查这个问题我见过很多面试者只写一句检查网络通不通然后就没下文了。实际上一个完整的排查链条应该是这样的先确认应用到数据库的网络连通性用ping测ICMP、用telnet 数据库IP 端口测TCP连接然后看数据库侧的端口监听ss -tnlp再查数据库的最大连接数是否打满show variables like max_connections和show status like Threads_connected如果连接数没满还要看是不是连接被防火墙拦了或者数据库负载太高导致accept队列打满。TCP握手这块有个高频知识点为什么会有TIME_WAIT状态因为主动关闭连接的一方在发送最后一个ACK后要等待2MSL最大报文段生存时间才能释放连接目的是确保最后的ACK能被对方收到如果丢了可以重发。在连接频繁建立和关闭的场景下TIME_WAIT连接过多会造成端口资源耗尽出现Cannot assign requested address错误这也是数据库连接池偶发连接失败的常见原因之一。DNS也是容易被忽略的地方。应用连接数据库如果用的是域名而不是IP每次建连都要做一次DNS解析如果DNS解析慢或者有超时表现也是连接超时。排查时可以nslookup或dig看解析耗时也可以建议应用侧做DNS缓存。这个考点通常不会单独出题但放在故障排查综合题里是很漂亮的加分点。3.3 Shell脚本与自动化运维工程化的敲门砖说实话校招笔试里直接考Shell脚本写的题目不算多但网易这种级别的公司很有可能会在笔试或面试里让你写一段处理日志的脚本或者让你说说如何批量检查100台机器上MySQL实例的运行状态。这个考点的本质不是考语法是考自动化意识。你做运维面对的是一堆机器和一堆实例如果不能把重复操作自动化效率和出错率都没法看。所以哪怕笔试没考到我也建议你在备考时认真练一练Shell脚本。一个比较典型的考察方向是日志分析。比如给你一个nginx访问日志让你统计出访问量最高的前10个IP。写成Shell就是awk {print $1} access.log | sort | uniq -c | sort -rn | head -10。如果条件换一下比如要统计某个时间段内的请求量就要用awk先过滤时间字段再按分钟或小时做聚合。另一个方向是批量操作比如写一个脚本SSH到多台机器执行同一个命令那就要用到for循环和远程执行参数。注意脚本里要考虑超时、失败重试、日志输出这些细节面试官看到你能想到这些说明你考虑过真实场景不是一个只会背语法的学生。实操心得Shell脚本容易出现本地没问题到生产环境就报错的情况很大原因是没做兼容处理。比如用#!/bin/bash指定解释器、检查关键变量是否为空、命令不存在时的fallback逻辑。还有一点写脚本时养成用set -euxo pipefail开头的好习惯至少要有set -e这样脚本出错时会立刻退出而不是继续往下跑导致更严重的问题。4. 如果重回考场答题策略与延伸学习建议这一章不说知识点了说点更实在的话拿到一份笔试卷怎么分配时间、怎么组织答案、怎么从真题延伸出一个完整的备考体系。我在一线做运维这么多年也帮公司筛过不少简历和笔试卷站在出题人的角度有一些心得体会想分享给你。4.1 笔试时间分配与答题思路数据库运维笔试卷通常是选择题、简答题、SQL题、场景分析题的组合。我建议的策略是选择题快速横扫不会的标记出来最后再回来蒙不要在单题上耗超过2分钟SQL题认真写这类题通常有明确的正确答案是送分题但也是最容易因为细节丢分的——表名写错、漏掉WHERE条件、忘记去重任何一个低级错误都会让你和后面的同学拉开差距简答题和场景题留够时间因为你不仅要写出结论还要能展示完整分析过程。答题思路上有一个关键技巧答案要有层次感。先用一句话给出结论再说依据和推理过程最后补一个边界条件或注意事项。举个例子题目问为什么这个SQL没用索引不要只写因为索引失效可以这样答结论是这个查询条件里对索引列做了函数运算依据是B树的叶子节点按原值排序函数运算后无法利用排序结构做快速查找建议改成WHERE create_time 2024-01-01 AND create_time 2024-01-02这种范围写法既能走索引又保持了语义。这种三段式回答判卷人扫描起来舒服你拿到分数的概率也高。4.2 从真题延伸到今天一份补充学习清单如果你不想只盯着这份2018年的卷子还想把知识版图扩展到今年校招面试的高频方向我把最近几年越来越重要的几个方向整理成了一张清单。第一个是国产数据库。达梦、人大金仓KingbaseES、GaussDB、OceanBase、TiDB这些名字在现在的运维招聘里出现的频率越来越高。很多国企和政企项目已经明确要求使用国产数据库厂商认证培训都排得很满。我建议你至少装一个达梦或者人大金仓的社区版跟着官方文档把安装、建库、迁移、备份走一遍。你会发现在Linux上的部署逻辑和MySQL很接近但很多细节不同比如语法兼容性、表空间管理、命令行工具提前摸过一遍面试时提到你会用过国产数据库是很明显的加分项。第二个是分布式数据库和云原生数据库。TiDB、OceanBase这种原生分布式数据库笔试可能不会深入考实现原理但你要知道它们和单机MySQL的本质区别分布式事务、自动分片、弹性扩缩容、多副本一致性。如果被问到什么场景适合用分布式数据库你的思路应该是从数据量、写入吞吐、扩展性、成本几个维度去分析而不是背一句分布式数据库很牛。云数据库比如阿里云RDS、腾讯云TDSQL也是同样的思路你要理解托管数据库和自建数据库的利弊。第三个是向量数据库。这个方向是最近两年才热起来的跟AI应用关系很大。面试官可能会问一句向量数据库和传统数据库有什么区别。你只需要讲清楚向量数据库存的是向量一组浮点数检索的方式是近似最近邻搜索比如HNSW算法典型场景是RAG、相似图片检索很多从MySQL、PostgreSQL扩展出来的向量能力也在快速发展。这块不需要深究算法但知道概念、知道实际应用场景已经能让你跟上行业节奏。第四个是数据库同步工具。现在很多公司的数据要从业务库同步到数仓、同步到异构数据库这一类工具如Canal、Debezium、DataX、Flink CDC在校招面试中的出现率越来越高。核心考点在于基于binlog的增量同步原理、全量同步与增量同步的衔接、同步延迟的监控与处理。理解了MySQL主从复制的原理后这些工具学起来会非常快。4.3 校招备考中容易踩的坑最后说说我在带校招生和看笔试答卷时最常看到的问题。这些都是真话你提前知道至少能避开一半的坑。第一个坑是只看不练。很多人复习数据库原理翻了一堆博客和面经觉得自己懂了结果一上手写SQL或者分析执行计划就露馅。我的建议是备考期间一定要动手搭一套环境MySQL装起来造几万条数据把索引、事务、日志、主从复制全部亲手过一遍。不需要很复杂的机器一台4G内存的虚拟机就够。纸上得来终觉浅这句话用在数据库技术上再合适不过。第二个坑是不注意版本差异。MySQL 5.7和MySQL 8.0在不少特性上差别很大比如8.0默认字符集变成了utf8mb4、取消了查询缓存、增加了窗口函数、binlog格式默认是ROW。笔试题目如果没说明版本你回答时可以用以MySQL 8.0为例来限定范围这样既显得严谨也避免因为版本问题被扣分。第三个坑是会做不会说。笔试是文字表达你写得出来不代表面试时你能说出来。建议在准备阶段每做完一个知识点尝试用自己的话复述一遍就当作在给一个完全不懂数据库的同事讲。如果你能讲到对方听懂那才算真的掌握了。这个能力在面试环节尤其重要因为面试官问的很多问题都是让你讲一下分析一下。5. 写在最后一份老运维的真实建议这篇文章从网易2018年的笔试卷出发把数据库运维校招笔试的核心考点、答题策略和延伸学习方向都过了一遍。说到底笔试只是你进入这个行业的第一道门它考察的永远不是你背诵的能力而是你有没有建立一套完整的知识体系、有没有动手实践的经验、有没有面对复杂问题时冷静分析的习惯。我见过太多同学把大量时间花在刷题上这是有必要的但不是全部。真正能让你从同龄人里脱颖而出的是你在准备过程中积累的对系统的理解、对故障的感知、对细节的执着。这些能力不是靠笔试题目本身获得的而是靠你一遍遍亲手操作、踩坑、复盘得来的。所以如果你现在正在准备校招我的建议是拿一份真题不要先看答案限时2小时认真做一遍然后对照答案解析把每个考点都标记出来再按这篇文章的思路把知识体系补齐。整个过程不要追求快要追求扎实。等你把MySQL装了一遍、把主从复制搭了一遍、把一次死锁亲手复现了一遍你会发现笔试和面试都只是水到渠成的事。最后再分享一个小技巧把每次做错的题、没答上来的知识点记到一个笔记里每周翻一遍。考前一周重点看这些笔记比再刷一遍完整题库有效得多。这个过程很枯燥但数据库运维这个行业本来就没那么多捷径可走。共勉。