游戏公司的数据库管理工程师笔试和传统行业不太一样。搜狐畅游2019校招的这套数据库管理工程师笔试题表面看考的是MySQL语法和基础概念实际上筛的是“能不能在游戏业务的高并发场景下把数据库稳住”的人。游戏后台和普通业务后台最大的区别在于数据特征很明显玩家在线量有波峰波谷数据分区分服热数据集中在登录、排行、交易这几个环节又要保证数据最终一致又不能因为数据库锁把玩家体验搞坏。这篇文章就围绕这份笔试题涉及的考点做一次复盘拆解把游戏DBA笔试中反复出现的知识点、答题套路、以及备考时容易忽略的细节都捋一遍适合准备校招笔试的同学参考。1. 游戏公司的数据库笔试筛的其实是“业务敏感度”1.1 一份笔试题背后的岗位画像搜狐畅游是游戏公司旗下的网游产品线对数据库的要求很明确玩家表、角色表、装备表、订单表这些核心数据不能丢登录高峰期的读写压力要扛得住合服、跨服战、活动开奖这类逻辑又要求数据一致性和并发控制同时到位。所以DBA笔试题不会只在“背概念”这个层面打转而是会把知识点揉进游戏运营场景里考。2019年校招这套题的分值分布我没法一一列出来但从后来面试复盘的情况看整张卷子逻辑很清楚先拿基础题确认你的下限再用场景题确认你的上限。基础题考增删改查、事务、索引这些场景题则围绕“玩家同时操作”“排行榜实时更新”“服务器合并”这些游戏业务里真实会遇到的问题展开。你如果只刷过普通的管理系统面试题看到这些场景题会明显觉得“这个我好像懂一点但不知道从哪里下手”。1.2 从热搜词反推考题范围我当时备考的时候。喜欢把网络热词里和数据库相关的关键词收集起来聚成考点分布图。这套方法放到搜狐畅游这套题上同样适用。把“数据库”相关热搜词过一遍能发现它们高度集中在几个方向基本操作、性能优化、并发控制、高可用、国产化替换、工具链使用。这不是巧合游戏公司DBA日常工作就是围绕这几个方向转的。微博、百度这类平台上的热搜词有一定的滞后性但这反而能代表企业招聘时的真实需求热搜词里大量出现“数据库死锁”“数据库并发锁”说明并发控制是行业痛点“数据库同步软件”“数据库always on”“数据同步工具”说明高可用方案是岗位刚需“达梦数据库”“人大金仓数据库docker”“国产数据库排名”则对应国内数据库国产化的大趋势。把这些关键词映射到笔试题型上可以整理成下面这张表。热搜关键词聚类对应考点笔试题中的常见考法数据库增删改查、数据库sqlSQL基本功、事务手写SQL判断事务隔离级别数据库死锁、数据库并发锁InnoDB锁机制、死锁排查给出并发操作分析死锁可能发生的原因索引、慢查询、数据库查询索引设计、执行计划给一条慢SQL要求优化mysql连接池、连接管理连接池模型、参数配置计算合适的连接数排查连接泄漏主从复制、同步工具、always on高可用架构、数据同步描述主从延迟的排查思路mysqldump、备份恢复备份策略、故障恢复设计一个备份恢复方案达梦、人大金仓、国产数据库数据库迁移、兼容性开放题讨论去O或国产化替换试卷里具体题目记不太清了但大致就是上面这几个模块。后面我会把每个模块的核心知识点和答题思路展开讲。2. 笔试题里反复出现的六个技术考点2.1 增删改查与事务基本功题不能丢分这类题看着简单实际上笔试最容易丢分的点就在“基础”两个字上。一份卷子第一题往往就是手写一个玩家充值记录的插入和更新SQL能不能把事务边界写对能直接看出平时的编码习惯。举个例子游戏中玩家购买道具逻辑上要扣余额、加道具、写流水。如果不用事务这三条语句中间任何一步失败玩家余额就丢了或者道具到手但钱没扣这都属于线上事故。正确写法是START TRANSACTION; UPDATE user_account SET gold gold - 100 WHERE uid 1 AND gold 100; INSERT INTO user_item (uid, item_id, item_count, create_time) VALUES (1, 1001, 1, NOW()); INSERT INTO gold_flow_log (uid, change_amount, balance, create_time) VALUES (1, -100, (SELECT gold FROM user_account WHERE uid 1), NOW()); COMMIT;这里有两个细节笔试可能会单独拿出来问扣余额的UPDATE语句必须带AND gold 100这样在并发情况下如果余额不足影响行数为0业务层就能判断“购买失败”而不需要依赖锁。流水表写入最好和主业务放同一个事务保证对账时不会出现“钱扣了但流水丢了”的情况。事务的ACID属性也常考特别是隔离级别。MySQL默认是REPEATABLE READ笔试经常会问“为什么不用READ COMMITTED”。回复要点是InnoDB在REPEATABLE READ下通过MVCC解决了普通读的幻读问题同时RR也是官方默认值很多线上配置会保持默认。但是高并发场景下RR会给读操作加next-key lock导致锁范围变大所以有些公司会主动切到READ COMMITTED。2.2 索引与慢查询一道SQL优化题能刷掉一半人游戏业务里慢查询主要集中在排行榜、玩家信息查询、公会列表这三个地方。笔试的SQL优化题基本就长这样假设有玩家表playerCREATE TABLE player ( id INT NOT NULL AUTO_INCREMENT, account VARCHAR(32) NOT NULL, role_name VARCHAR(64) NOT NULL, server_id INT NOT NULL, level INT NOT NULL, exp INT NOT NULL, last_login_time DATETIME NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_account_server (account, server_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;一条查询是SELECT role_name, level FROM player WHERE server_id 5 AND account test01 ORDER BY last_login_time DESC LIMIT 10;你判断这条SQL需不需要优化如果优化怎么加索引正确思路是先把可能的索引列出来。account和server_id已经有联合唯一索引但那是用来查账号是否存在的。查询条件里有等值匹配server_id 5 AND account test01这两个字段的组合其实命中uk_account_server。如果查询结果是单条那这条SQL没问题但结合ORDER BY来看目标应该是查出某个账号在这组条件下的登录记录那account字段可能并不是等值条件。真正的答案是先确认查询意图再决定索引。这种题的核心考察点不是“索引怎么加”而是“加索引之前先看执行计划”。我笔试时直接写了一条优化思路1. 用 EXPLAIN SELECT ... 看 type、key、rows 字段 2. 如果 type ALL说明全表扫描考虑加联合索引 3. 等值条件放前面排序字段放最后例如改成ALTER TABLE player ADD INDEX idx_server_level (server_id, level);当查询条件简化为server_id 5 ORDER BY level时能同时满足等值过滤和排序这是最典型的最左前缀用法。B树索引有序性在这里的价值就体现出来了——索引不仅过滤行还能省掉filesort。答题时如果只写“加个索引”四个字基本拿不到分。必须写清楚加在哪几个字段上、为什么放这个顺序、怎么验证加索引后的效果。2.3 死锁与并发控制考的是“定位问题”的能力死锁是游戏数据库笔试的高频考点因为游戏里的道具交易、拍卖行竞拍、活动奖励发放都是典型的并发转账场景。死锁题不会只问定义而是给一个并发时序让你判断有没有死锁风险并说出怎么避免。比如两个事务-- 事务A UPDATE user_account SET gold gold - 100 WHERE uid 1; UPDATE user_account SET gold gold 100 WHERE uid 2; -- 事务B UPDATE user_account SET gold gold - 100 WHERE uid 2; UPDATE user_account SET gold gold 100 WHERE uid 1;如果事务A和事务B同时执行A锁住了uid1的行等uid2B锁住了uid2的行等uid1形成循环等待InnoDB会检测到并回滚其中一方。答题时讲清楚“锁顺序不一致导致交叉等待”就够了但高分回答还要说清楚怎么解决。解决方案有三层统一锁顺序所有事务都按uid升序加锁A先锁uid1再锁uid2B也必须按同一顺序就不会循环等待。控制事务大小把不必要的行锁范围缩小比如先查询需要的UID列表一次性排序后再更新。设置合理的锁等待超时innodb_lock_wait_timeout调小一点避免事务长期挂起拖垮数据库。笔试如果出“线上数据库死锁怎么查”你得能写出具体命令SHOW ENGINE INNODB STATUS\G重点看LATEST DETECTED DEADLOCK段里面会给出死锁事务的SQL语句、持有锁和等待锁的细节。回答时如果能补充一句“死锁发生时InnoDB会自动回滚代价较小的事务所以错误日志里能看到一条事务返回1213错误”会显得更有实战经验。2.4 连接池不是背参数而是算数数据库连接池的题笔试喜欢考“为什么不用每次都新建连接”和“连接池大小设置多大才合适”。第一个问题很简单一次数据库连接的建立要经过TCP三次握手、MySQL权限校验、连接对象创建耗时可能几十毫秒高并发下根本扛不住。连接池复用连接把创建连接的耗时从请求关键路径里去掉。第二个问题才是拉分点。很多人背的是“maximumPoolSize CPU核心数 * 2 磁芯消耗数”这个公式但笔试更想看到你能理解它背后的原理数据库连接是稀缺资源连接数越多数据库端的线程切换和上下文切换开销越大吞吐量反而会下降。所以连接池上限不是越大越好需要根据CPU核数、SQL耗时、目标并发量做估算。我当时是这样答的假设目标QPS 500平均SQL耗时 10ms那么单连接每秒最多处理100个请求。 需要的连接数 ≈ 500 / 100 5。 考虑到网络抖动和慢SQL再乘1.5倍约等于8。这个计算方式比背公式更符合实际也更容易让面试官眼前一亮。如果题目问“连接池连接泄漏怎么排查”要能答出SHOW PROCESSLIST里大量Sleep状态的连接、应用日志里的获取连接超时、Druid或HikariCP监控面板里的活跃连接数持续接近上限这几个典型特征。2.5 主从复制与数据高可用游戏合服/跨服的底层依赖游戏运营到一定阶段经常会做合服、开新服、跨服战场这些操作背后都依赖主从复制和数据迁移。笔试里关于主从复制的题一般从原理和故障排查两个维度出。先说原理。MySQL主从复制是binlog驱动的主库把变更写入binlog从库的IO线程拉取binlog写入relay logSQL线程再重放relay log。整个链路如果某个环节出问题就会出现主从延迟或数据不一致。笔试常问“半同步复制和异步复制有什么区别”回答半同步时主库要等至少一个从库确认收到binlog才提交事务能降低丢数据的风险但会增加RT异步复制性能好但主库宕机时可能丢事务。再说故障排查。题目可能是“从库延迟越来越大怎么排查”。答题模板可以这样写先确认延迟量SHOW SLAVE STATUS\G看Seconds_Behind_Master看从库为什么追不上大事务、无主键表、从库硬件不够、主库写入量过大都可能导致延迟针对性优化大事务拆批、给所有表加主键、升级从库机器、或者引入并行复制slave_parallel_workers 0游戏合服时主从切换是高频动作笔试如果出“主库宕机后怎么把从库提升为主库”要答得保守一点先确认数据一致性优先处理relay log里未回放的事务再执行只读设置、提升从库、修改应用连接配置。千万不能说“直接STOP SLAVE; RESET SLAVE;就完事”。2.6 备份恢复最后一道保命题备份相关题目通常放在笔试试卷靠后的位置但分值不低。游戏DBA和业务DBA最大的区别在于玩家的虚拟资产几乎就是真实资产丢失数据不只是技术事故还会引起大面积客诉。备份恢复题一般从“选择备份类型”和“设计恢复流程”两个角度出。备份类型对比常这样考备份类型工具优点缺点逻辑备份mysqldump跨版本恢复方便可选择性恢复速度慢备份大表会占资源物理备份XtraBackup速度快备份粒度细版本兼容性要求高恢复依赖相同环境增量备份binlog恢复粒度到秒需要完整备份做基础binlog必须连续答题时先说清楚线上场景怎么选核心游戏库通常用物理全备 binlog增量恢复时长要求高的库还会配合延时从库。然后写恢复主流程先恢复最近一次全备再重放binlog到指定的时间点或位置。如果题目给了一个“删表误操作”的案例要记得回答里补一句“恢复前先把当前binlog备份好防止二次写坏”。3. 拿到笔试卷之后按什么顺序答才能拿高分3.1 选择题判断题先排除绝对化表述数据库笔试题里的选择题有些选项一看就该排除。比如“只要加了索引查询就一定快”“READ COMMITTED能完全避免幻读”“主从复制能实时同步数据”这些带“一定”“完全”“实时”字样的说法基本都是错的。真实环境里任何方案都有边界条件。我备考时习惯把做错的判断题整理成“反常识清单”比如“索引对DML语句的性能一定是有损的”这句话就不完全对因为覆盖索引可以减少回表在一些场景下反而能让UPDATE走索引更快。这种题的拉分点不在记忆而在理解的准确度。3.2 简答题别上来就堆术语先给结论简答题最忌讳只贴概念。题目问“主从延迟的解决方案”你如果从binlog开始讲起讲半天讲不到重点阅卷体验很差。我的习惯是先用一句话给结论再分点展开。举个例子问从库Seconds_Behind_Master持续增长怎么处理 答优先处理大事务和从库回放能力不足两个方向。 1. 确认当前延迟量先查 SHOW SLAVE STATUS\G 2. 检查是否存在一次操作几十万行的大事务如果有拆成小批量执行 3. 检查从库CPU/IO饱和度确认是否需要升级配置 4. 开启并行复制增加回放效率 5. 如果还顶不住考虑只读业务降级或分流这种“结论先行 分点展开 可操作命令”的结构比单纯写“优化SQL”要强很多。因为阅卷人能在10秒内判断你有没有实际经验。3.3 手写SQL题正确优先顺手写注释手写SQL是笔试题里最容易拉开差距的部分。很多人一上来就写窗口函数、临时表结果语法错误一分没有。我的建议是能先用简单写法保证正确再用优化版本展示能力。比如“查询每个服务器中等级最高的玩家”简单写法是SELECT server_id, id, role_name, level FROM player ORDER BY server_id, level DESC;如果题目要求取每个服第一名最好用关联子查询或者窗口函数但要注意MySQL版本是否支持窗口函数。8.0支持5.7不支持。2019年笔试时的主流版本还是5.7所以用关联子查询更稳妥SELECT p.server_id, p.id, p.role_name, p.level FROM player p WHERE p.level ( SELECT MAX(level) FROM player WHERE server_id p.server_id );把两种写法都写上并注释一句“5.7版本用子查询8.0也可以改成ROW_NUMBER()”阅卷人会觉得你是真了解版本差异的。3.4 场景设计题把“业务场景”几个字刻在脑子里场景设计题是整套题里最像真实项目的部分。2019年搜狐畅游这类游戏公司笔试基本不会只考“设计一张玩家表”这么简单而是会叠加需求比如“玩家排行榜要实时更新日活高读写比例大约是10:1你怎么设计表结构和索引”。这种题的高分回答是分层的先确认需求。排行榜是全部服共享还是分服排名实时性要求是秒级还是分钟级再说表设计。如果实时性要求高直接用排名表rank_list(server_id, role_id, score, update_time)加覆盖索引(server_id, score)查排名。最后说业务侧降级。可以定时计算排名后写入缓存或者用Redis有序集合做前十名展示数据库只保留最终数据。答场景题的核心是“把方案讲成一套技术选型故事”不是零散地说“我加个索引”。面试官也知道你们应届生没真做过游戏项目他们想看的是你遇到需求时有拆解意识。4. 备考时容易忽略、考场上却容易翻车的地方4.1 国产数据库与厂商数据库的开放题题库里经常冷不丁出一个“谈谈对国产数据库现状的看法”或“达梦数据库和MySQL有什么区别”。这类题让很多只刷MySQL的考生懵住。答题不需要你彻底用过达梦但得有迁移兼容性的思考框架。达梦和MySQL都支持标准SQL但存储引擎、分区语法、系统视图名字不一样。迁移的核心不只是把SQL改通还得考虑主从复制机制、备份恢复方式、应用侧驱动兼容性。如果笔试现场遇到“达梦数据库安装”相关关键词别慌它大概率不是问安装命令而是问迁移思路。你可以从“兼容性评估、数据迁移工具链、应用改造、灰度切换”四个阶段答即使没有实战经验也能体现数据库领域的整体视野。人大金仓、GaussDB这些国产数据库在热搜词里出现频次也很高说明行业方向已经变了。会MySQL不代表会国产数据库但迁移经验是通用的先在测试环境把SQL跑一遍找出兼容性问题再设计双写方案过渡。这个思路放在任何数据库迁移题里都能用。4.2 新兴数据库方向向量数据库、时序数据库“向量数据库”和“时序数据库”近几年在招聘热词里出现频率越来越高。2019年笔试考到的可能性不算大但现在复盘时可以作为一个延展知识点准备。向量数据库主要服务AI场景里的相似度检索比如以文搜图、以图搜图时序数据库则处理大量时间戳数据比如游戏在线人数曲线、服务器性能监控。如果考题问“游戏日志数据该存MySQL还是时序数据库”答题要点在于区分业务型和时序型数据。游戏运行日志、玩家行为轨迹不需要强事务按时间范围查询多、写入量大适合存时序数据库玩家账号、道具、订单这类需要强一致性的数据放MySQL。答这种题不要只给结论要说明判断标准有没有频繁更新、事务要求、数据生命周期、查询模式。4.3 笔试中的“工具题”数据库同步软件、dbx数据库工具热搜词里出现“dbx数据库工具”看起来更像开发运维工具。笔试不太会直接考具体工具怎么用但可能出现“数据库同步工具选型”这类题。遇到工具题不要慌把工具分类讲清楚就行数据同步类canal、DataX、Maxwell一般做异构数据同步或增量同步数据库管理类Navicat、DBeaver、dbx用于日常连接和查看备份恢复类mysqldump、XtraBackup如果题目问“主库到备库的数据同步怎么做”不要只答MySQL主从还可以说拿Canal监听binlog同步到其他存储比如同步到Elasticsearch做搜索。这样回答能把“数据库管理工程师”的岗位边界撑得更宽一点显得你不只是会数据库本身还懂周边生态。5. 笔试结束后怎么把这份卷子变成面试的加分项5.1 回顾错题总结成自己的话术笔试交卷那一刻趁记忆还在把不确定和不会的题都记下来。我当时用的办法是画一张“错题知识地图”把所有错题对应到的知识点归到“基础语法、索引优化、锁与事务、高可用、备份恢复、工具链”这六个大项里。面试前不用重新看一遍数据库教材只复习这张地图就够。面试官很喜欢在面试里问“上周笔试有几道题你印象比较深”如果你能直接说出某道题的最优解路径比笼统回答“我觉得我还有很多要学”要靠谱一百倍。5.2 把笔试题延伸成一次小实验笔试中的场景题可以在本地环境亲手验证一遍。比如笔试出了主从延迟你就在本地搭一个MySQL主从复制压入大量数据看看延迟怎么变化笔试出了死锁你就写两个事务手动制造死锁再用SHOW ENGINE INNODB STATUS查看记录。这比刷一百道题都管用。我当时为了搞清楚“索引为什么能消除filesort”专门建了一张10万行的表加上联合索引后比较ORDER BY的执行计划。实验做完无论笔试还是面试遇到排序优化的问题都能讲得明明白白。5.3 一个可复用的备考时间线最后说一下时间安排。如果用三周备考一套游戏公司DBA笔试题我会这样分配第一周过基础。SQL增删改查、事务隔离级别、索引原理配合刷题巩固。第二周攻难点。锁机制、死锁、主从复制、高可用架构每两天动手搭一个环境验证。第三周做综合题。把热搜词里的场景题、工具题、开放题都过一遍练“结论先行”的表达结构。这样下来即使遇到没见过的国产数据库开放题也能靠迁移思路和系统化的答题框架撑住。我个人在复盘这套搜狐畅游笔试题时最大的感触是笔试考的不是“知识点记忆”而是“遇到问题有没有一套稳定的分析框架”。数据库这个方向内容太多不可能什么都准备到但只要有业务场景意识、能说清楚方案背后的取舍依据就算遇到没见过的题也能答到点子上。这套备考思路不只是针对游戏公司凡是偏重数据库稳定性和数据一致性的岗位笔试基本都是同一个套路。