搜狐畅游2019校招笔试题-数据库管理工程师这个标题放在今天看依然很有嚼劲。游戏公司的数据库笔试向来跟纯互联网业务团队不太一样它不会只问你B树有几层、索引怎么建而是会把场景摆在“玩家账号丢了怎么办”“排行榜实时刷不出来”“日志库一夜涨了几百G”这些真实到不行的问题上。对准备校招的应届生来说这类题目正好是检验自己数据库功底的试金石对已经工作几年的同行回头再看这些考点也能摸到游戏行业DBA的核心能力模型。这篇文章我就以当年搜狐畅游数据库管理工程师笔试题为切入点结合游戏行业DBA的日常工作场景把笔试背后真正想考察的东西拆开揉碎讲清楚哪些知识点必须死磕、哪些坑容易踩、怎么准备才高效。内容覆盖SQL基本功、事务锁机制、高可用架构、运维管理以及游戏行业特色场景题适合正在准备校招的计算机相关专业学生也适合想转行做数据库方向的同学参考。1. 从一份游戏大厂的DBA笔试题说起1.1 这道题考的不是“会不会”而是“敢不敢碰生产环境”搜狐畅游作为老牌游戏厂商旗下产品线多、运营时间长数据库团队面对的是典型的游戏业务场景海量玩家并发、频繁的版本更新、7x24小时不能停服。这种背景决定了校招笔试不会只考教科书上的理论而是会通过场景化题目来判断你有没有生产意识。我见过不少同学复习数据库笔试时只盯着“三范式”“事务ACID”这些概念背结果一碰到场景题就懵。比如题目问“玩家充值记录误删了怎么办”有人上来就答“用flashback恢复”这在Oracle环境或许可行但在MySQL环境就是废话。实际上笔试官想听的是先确认binlog有没有开、恢复点在哪、有没有备用库可以切换、恢复期间怎么保证玩家体验不受影响。这就是生产思维和理论思维的区别。1.2 游戏行业DBA的日常决定了笔试的出题方向游戏公司的数据库管理工程师日常干的事情跟电商、金融行业的DBA有重叠但也有明显区分。核心业务库要保证玩家账号、角色、背包、充值数据绝对可靠日志分析库要承接每天几十亿条的行为埋点运营后台库要支撑活动配置、公告发布、道具发放。这些场景混合在一起就构成了笔试题库的主要来源。我在拆解这些年游戏公司DBA笔试时发现出题方向基本固定在四块SQL基本功、事务与锁、高可用与容灾、性能调优与运维管理。每一块都有对应的典型场景题比如排行榜实时更新怎么设计、全服邮件群发怎么不拖垮数据库、跨服战数据怎么同步。理解了岗位日常再看题目就不会觉得散而是一条清晰的技能树。2. SQL基本功写对只是及格线写快才是得分点2.1 单表查询、多表JOIN与子查询这些题其实在考执行计划很多同学觉得笔试题里的SQL很简单不就是SELECT、WHERE、GROUP BY吗但实际上手写的时候细节决定成败。比如“查询每个服最高等级玩家”这道经典题有人用GROUP BY MAX有人用窗口函数ROW_NUMBER()还有人用关联子查询。三种写法结果一样但执行效率差异巨大在百万级玩家表上高下立判。笔试阅卷时面试官其实不太care你用的哪种写法而是看你能不能分析出每种写法的执行计划。以MySQL为例GROUP BY会触发临时表和文件排序关联子查询可能会造成DEPENDENT SUBQUERY逐行扫描而窗口函数在8.0版本后走的是优化过的窗口算子。你如果能在答案里写清楚“这里用关联子查询会导致外层表每行都执行一次内层查询数据量大时会很慢”这比单纯写对SQL要高一个档次。2.2 DML操作在笔试里的几个容易翻车的点增删改查CRUD是最基础的但笔试里的INSERT、UPDATE、DELETE往往埋了坑。最常见的是UPDATE不带WHERE条件的全表更新这种错误在笔试现场犯一次印象分直接崩。另一个高频考点是批量插入的性能问题循环单条INSERT和一条INSERT多VALUES的差距在游戏开服导角色数据时能差出几十倍。还有个细节很多人忽略DELETE数据后表空间不一定会释放。在InnoDB引擎下DELETE只是打标删除物理空间要等purge线程清理而且表文件大小不会自动收缩。笔试里如果考“清理一张10亿行的日志表怎么让磁盘空间真正释放”答案就不是简单的DELETE而是要涉及分批删除配合OPTIMIZE TABLE或者直接建新表导数据再重命名。这种题就是典型的“看着简单实际考运维经验”。2.3 索引失效场景这是SQL题里性价比最高的考点索引失效的考点几乎年年考因为它是线上慢查询的头号原因。常见场景就那么几个对索引列使用函数、隐式类型转换、LIKE前置通配符、OR条件连接非索引列、联合索引不满足最左前缀。笔试里通常会给一条慢SQL让你分析为什么慢、怎么优化这本质就是在考这些失效场景。我记得有一道很有代表性的题目某表user_id是varchar类型但代码里传了数字类型导致索引失效全表扫描。这种问题在校招项目里很常见因为学生用框架ORM时很少关注字段类型映射。笔试里如果能把“隐式转换会导致索引列上的类型转换让优化器放弃索引”这个原理讲透再给出两种解决方案改SQL传参类型或者改表字段类型基本就是满分回答了。3. 事务、锁与并发DBA笔试的“分水岭”3.1 隔离级别与MVCC的底层逻辑不能只会背名字事务这块是区分“背过书”和“真懂”的分水岭。笔试常考四种隔离级别但如果你想拿高分不能只答“读未提交、读已提交、可重复读、串行化”而要把每个级别解决了什么问题、引入了什么问题讲清楚。更关键的是MVCC机制。MySQL InnoDB默认的可重复读隔离级别靠的是undo log版本链和ReadView来实现快照读这一块很多同学理解得模模糊糊。我建议准备笔试时画一张图每条记录上有trx_id、roll_pointer每次更新生成新版本ReadView里记录活跃事务列表判断当前事务能看见哪个版本。把这个逻辑理清了笔试里“当前读和快照读的区别”“为什么可重复读级别下还是会出现幻读”这类问题就能答到点子上。3.2 死锁的成因与处理笔试现场最常见的压轴题数据库死锁在笔试里基本是必考而且通常会结合场景两个事务分别更新两张表顺序相反互相持有对方需要的锁于是死锁。答案的套路很固定先说死锁四必要条件互斥、持有并等待、不可剥夺、循环等待再结合具体的SQL分析哪一步产生了循环等待最后说解决方案。但我想说的是死锁题目答到“按固定顺序加锁”只是及格。真正拉开差距的是你对死锁检测和处理的了解。比如MySQL InnoDB通过等待图wait-for graph检测死锁检测到后会自动回滚代价更小的事务比如参数innodb_lock_wait_timeout表示等待锁的超时时间默认50秒还比如通过SHOW ENGINE INNODB STATUS看LATEST DETECTED DEADLOCK信息里面会清楚打印出两个事务持有什么锁、在等什么锁。把这些讲出来面试官会觉得你是真处理过线上问题。3.3 数据库并发锁与连接池看似不相关实则强关联笔试里有时候会把锁机制和连接池放在一起考比如“连接池最大连接数设置太大会不会有问题”。很多同学觉得连接池就是调参没什么技术含量实际上连接池跟数据库锁、事务生命周期强相关。一个典型的坑是连接池开了50个连接业务代码里事务内做了耗时的远程调用导致50个连接全被占住后续请求全部等待获取连接而等待中的请求又占着应用服务器的线程最后整个服务雪崩。笔试如果出这种题核心考点就是事务里不能有网络IO以及连接池的maxActive、maxWait等参数要根据业务TP99来定。顺便说一句现在很多新项目用连接池框架HikariCP、Druid笔试可能会问Druid的监控页面能看到哪些指标或者HikariCP为什么快字节码优化、FastList、无锁集合这些属于加分项但也别答得太偏。4. 数据库架构与高可用从单机到集群的进化4.1 主从复制、读写分离与Always On怎么保证不丢数据游戏业务的特点是读多写少且读流量可能瞬间暴涨——比如新版本开服、全服活动开启这时候读写分离是标配。笔试里考主从复制通常会从两个角度切入一是原理层面binlog日志格式STATEMENT、ROW、MIXED的区别从库怎么通过IO线程拉日志、SQL线程回放二是延迟层面主从延迟怎么产生、怎么监控、怎么缓解。关于高可用方案很多同学听说过Always On但那是SQL Server的数据库镜像和可用性组功能MySQL里对应的是MHA、Orcherator、MySQL Shell等方案。笔试里如果在讲高可用建议先讲清楚RPO和RTO这两个指标。RPO是能容忍丢多少数据RTO是能容忍宕机多久。游戏公司通常要求RPO接近0RTO在分钟级甚至秒级。围绕这两个指标去设计主从切换、半同步复制、强同步方案思路就清晰了。4.2 数据库同步工具与异构数据迁移笔试题目如果涉及数据同步除了主从复制还可能会问到跨数据库实例的数据同步。这里就牵扯到一堆同步工具比如MySQL官方的binlog同步、阿里云的DTS、开源的Canal、Maxwell、DataX、Flink CDC等。其实这几年国产数据库生态越来越丰富笔试题里也开始出现“业务从Oracle迁移到达梦/人大金仓/OpenGauss要考虑哪些问题”这类题目。如果笔试提到国产数据库达梦数据库、人大金仓、GaussDB考点往往在“兼容性”上SQL语法差异、自增列实现方式、分页写法Oracle的ROWNUM和MySQL的LIMIT差异、存储过程语法兼容、工具链适配。别小看这类题很多项目迁移时最大的坑不是数据搬不动而是上层应用一堆SQL写法需要改。4.3 遇到“主数据库不可访问”这类场景题现场怎么排查相关热词里有一条很扎眼的描述“主数据库无法访问使用主数据库的功能将不可用。”这其实对应的是数据库故障场景题。笔试可能会给你一段描述让你分析可能的原因和排查步骤。我的排查经验一般分四步第一步看网络数据库端口不通先ping、telnet确认是不是网络策略变动第二步看实例状态进程还在不在、是不是被OOM killer杀了、监听有没有挂掉第三步看资源磁盘满了会导致数据库无法写入甚至拒绝连接CPU和内存是否被打满第四步看日志错误日志里有没有连接数超限、死锁、复制中断的记录。笔试里如果你能按这个层次回答条理清晰基本就是标准答案的节奏。另外如果你知道怎么用Zabbix/Prometheus/Grafana这类监控工具提前告警那就更贴合生产实践了。5. 运维管理核心备份、审计与调优一个都不能少5.1 备份恢复策略笔试必出的大题数据库管理工程师笔试基本必考备份恢复因为这是DBA最核心的职责。问法通常有两种一是直接问备份策略怎么设计二是给一个故障场景让你说怎么恢复。设计备份策略的时候要讲清楚几个层次全量备份多久做一次通常是每天增量备份多久做一次可以是每小时甚至每几分钟binlog要保留多久。恢复时讲究“全量增量binlog”三段式回放。有个容易忽略的考点备份要定期演练恢复否则备份文件可能早就坏了。在游戏公司账号数据是玩家的命根子笔试里经常考“误删一张玩家表怎么恢复”这时候要答出利用备份文件恢复到临时实例再导出指定表导入线上而不是直接把整个备份覆盖回去。5.2 数据库审计安全考点里的“暗线”近几年笔试开始多多少少涉及数据库安全和审计热词里也出现了“数据库开启审计引起索引争用”。这个点很实战很多数据库在开启安全审计后因为审计日志写得太频繁导致系统性能骤降甚至引发索引争用、锁等待飙升。笔试考审计的时候建议从“为什么审、怎么审、审了之后怎么办”三个层面答。为什么审合规要求和安全追溯能查清谁在什么时间做了什么操作。怎么审MySQL的general log性能开销大通常建议用init_connect配合binlog或者用专门的审计插件Oracle有统一的审计表国产数据库各有实现方式。审了之后怎么办不要让审计日志和应用共用磁盘要定期归档清理避免审计变成拖垮业务的元凶。如果能把这个闭环讲清楚面试官会觉得你有安全大局观。5.3 参数调优与慢查询分析手里的“三板斧”参数调优题在校招笔试里不会考太深但会考最基本的几个参数innodb_buffer_pool_size、max_connections、innodb_flush_log_at_trx_commit、sync_binlog。我建议按“为什么调、调到多少、调了有什么副作用”来准备。比如innodb_flush_log_at_trx_commit这个参数有三个取值0表示每秒刷盘性能最好但可能丢1秒数据1表示每次事务提交都刷盘最安全但性能最差2表示每次提交写操作系统缓存每秒刷盘性能和安全折中。游戏业务一般要求不丢数据通常会设成1但如果并发太高扛不住会和业务方商量改成2。笔试里如果考这个你要体现出“安全与性能的权衡”意识而不是死背参数值。慢查询分析也有固定套路先看慢查询日志找到耗时高的SQL用EXPLAIN看执行计划关注type、rows、Extra字段然后对症下药加索引、改写SQL、拆分大事务、或者做缓存。这套流程不复杂但每年还是有人答得零散。6. 游戏行业特色场景题排行榜、日志与时序数据6.1 排行榜实时更新一条SQL引发的“血案”游戏行业DBA笔试最有辨识度的题目就是排行榜设计。很多玩家每天上线就要看自己的战力排名、竞技场排名要求实时性很高。如果每次查询都对全表做ORDER BY在千万级玩家表上必然爆炸。合理的方案是分层在线层用Redis的有序集合ZSET存前1000名玩家查榜直接走Redis离线层定时用SQL任务计算全量排名刷新到榜单缓存表如果需要精确名次再在数据库里配合物化视图或单独榜单表做增量更新。笔试里答这道题时关键是体现出“缓存扛读、数据库扛写、异步算排名”的架构思维而不是纠结于某一条SQL怎么写。6.2 游戏日志库与时序数据库设计游戏的行为日志量非常大登录、登出、充值、战斗、道具消耗每天都是海量写入。这类数据的特点是写入量大、时间属性强、很少更新、常用于趋势分析和行为漏斗。现在很多团队会考虑用专门的时序数据库来承接热词里也提到了“时序数据库的数据库结构怎样设计”。如果笔试考日志库设计可以从两个方向答。传统方案是分库分表按天建表或者按月份分表配合数据生命周期管理定期把过期数据归档到冷存储。新一代方案是使用时序数据库比如InfluxDB、TDengine、Doris它们对时间分区、聚合查询、预计算有天然优化。说到Doris现在很多游戏公司用它做OLAP分析笔试如果提到“大宽表”“Rollup表”“聚合模型”你可以展开讲讲按维度预聚合的思路这会让面试官眼前一亮。6.3 运营分析、数据导入导出与数据库课程设计的差距很多应届生都有“数据库课程设计”的经历但笔试题目里的运营分析场景比课程设计复杂得多。课程设计可能只要做几个表的增删改查但游戏的运营分析要处理的是跨服数据合并、渠道数据对齐、充值流水和道具流水的关联分析。笔试可能考“Excel导入数据库”的工具和方法这时可以从三个层面答小数据量直接用IDE的导入功能或者Navicat向导中等数据量用LOAD DATA INFILE分批导入大数据量用DataX或Kettle做同步任务。类似地“导出数据库脚本”这个热词也对应笔试里的“把线上库表结构导出怎么保证脚本干净可用”的问题答案就是mysqldump加--no-data参数导出结构或者用专门的模型管理工具。7. 备考路径按真题题型拆解复习路线7.1 笔试现场的时间分配与答题策略搜狐畅游这类游戏公司校招笔试数据库管理工程师的卷子一般不会只有数据库题可能还有计算机基础、逻辑题、业务场景题。时间分配上我建议先扫一遍所有题目把会的、有把握的先做完再回头啃难题。数据库相关的大题通常分值高值得多花时间如果是选择题就不要反复纠结相信第一感觉。答题时还有个小技巧场景题尽量按“问题定位→分析原因→提出方案→方案对比→落地步骤→监控验证”的框架来写。即使你的方案不是最优解只要逻辑完整也能拿不少过程分。最怕的就是只写一句“可以用缓存解决”“可以加索引”没有任何展开这在阅卷人眼里跟没答差不多。7.2 系统复习路线别指望临时抱佛脚如果离笔试还有一两个月这里给你一个比较靠谱的复习顺序。第一周把SQL基础过一遍重点练多表JOIN、子查询、窗口函数每天手写10条SQL不嫌多第二周死磕索引和事务用本地MySQL建一张100万行的表自己EXPLAIN看执行计划模拟慢SQL优化第三周学高可用和备份自己在虚拟机搭一主一从演练一次主库宕机手动切换再做一次备份恢复这个过程比看十篇文章都有用第四周刷场景题尤其是游戏行业特色题排行榜、全服邮件、跨服战、日志分析每个场景都动手设计一遍方案。关于国产数据库和工具链如果时间充足建议装一个达梦或者人大金仓的试用版体验一下和MySQL在SQL语法上的差异。现在很多笔试题开始涉及国产数据库兼容适配有实操经验的人写出来的答案明显不一样。7.3 一些个人的体会和提醒最后说点心里话。我见过太多同学刷了一堆题但一上手连MySQL都装不利索。如果看到这篇文章的你正在准备数据库方向的校招我强烈建议先把MySQL装起来把binlog打开把慢查询日志打开然后拿一份开源的数据集或者自己写个脚本造数据每天在上面折腾。你会发现很多笔试里“背”的知识点在你亲手操作一次之后就再也不会忘了。另一个容易被忽视的点是数据库工具链的熟练度。热词里反复出现dbx数据库工具、Navicat、DBeaver、SQLiteStudio这类工具面试官不一定会直接考工具操作但如果你能在笔试的开放性题目里提到“我在本地用了某个工具做数据对比、做ER图逆向、做脚本导出”会显得你的工程化素养比只会写SQL的同学高出一截。工具不需要多但至少有一个用得很熟。数据库管理工程师这个岗位在游戏公司里不算最耀眼的但绝对是整个游戏世界稳定运行的底座。笔试只是一张入场券真正决定你能不能走远的是遇到问题时稳定的心态和清晰的排查逻辑。祝准备校招的你笔试顺利早日拿到心仪的offer。