前阵子有个学弟准备秋招翻出一份搜狐畅游2020校招数据库管理工程师的笔试回忆题来问我选择题还能对付手写SQL一紧张就想不起来场景题更不知道怎么下笔。我把这套题的核心考点按DBA日常工作的逻辑重新拆了一遍发现它其实不是死记硬背就能过的更像是把“数据库工程师平时怎么排查问题”压缩在一张卷子里。这篇文章就按我的复盘顺序来写先讲卷子结构再拆高频考点最后给场景题的答题框架。适合正在准备数据库岗校招、或者刚工作想补一轮数据库基础的人看。1. 卷子结构和考察意图出题人想要什么样的人1.1 一张数据库管理工程师笔试试卷的常见拼图互联网公司的校招笔试尤其是数据库管理方向题型通常不会太偏大体上由选择题、填空题、手写SQL、简答题和场景题组成。搜狐畅游这套卷子内部虽然不一定每年完全一样但从我接触过的同类题目来看分布大概是这样的题型大致题量/分值考察重点单选/多选20题左右占20分基础概念、参数、Linux命令、网络协议填空10题左右占10分术语定义、默认配置、端口、目录路径手写SQL3到4题占30分多表关联、聚合、分组、窗口函数、索引优化简答2题左右占20分事务、锁、隔离级别、备份恢复、主从复制场景设计/故障排查1到2题占20分架构选型、问题定位链路、业务理解这个结构很典型。前60分其实是在筛“基础扎不扎实”后面的40分才是真正拉开差距的地方。很多同学复习时喜欢抱着《数据库系统概论》背范式、背E-R图但实际笔试里关系代数出现概率极低反而SQL和运维场景占了大头。这一点要先有心理预期。另外一个容易被忽略的地方是笔试题里会出现不少“看起来是数据库题实际在考Linux和网络”的题目。比如问MySQL的默认端口、Redis的持久化配置、查看慢日志的常用命令、TCP三次握手和连接池的关系。这些都不是纯数据库原理而是日常运维必须碰的东西。游戏公司的DBA要跟账号服、充值服、区服运维打交道不会这些基本功笔试和面试都很难过。1.2 游戏业务里的数据库岗位到底做什么为什么游戏公司校招数据库管理工程师要考SQL和场景题而不是死板的理论因为游戏业务的数据库场景太典型了。一个最普通的游戏后台至少要支撑这几块账号系统用户注册、登录、token失效、角色系统角色属性、背包、装备、充值订单系统订单创建、支付回调、发货入账、运营活动系统活动配置、排行榜、邮件、日志统计系统玩家行为、充值流水、服务器监控。这些模块对数据库的要求不太一样账号和订单要求强一致背包和角色允许短时间内缓存延迟排行榜要求高并发读日志则是持续写入。笔试里那些看似零散的考点其实就是这些业务场景在纸面上的投影。比如考事务和死锁多半是为了应对“同一玩家同时充值并发货”这类并发问题考主从复制和备份恢复是为了提醒你游戏服可能半夜出故障你不能让全服玩家干等考索引优化是因为一条慢SQL打在充值表上整个区服都会卡。所以你在答题时不要把每个知识点孤立地背要能主动说清楚“这个方案能解决什么问题”“在什么业务场景下会用到”。哪怕题目没有明确要求简答题里主动带上场景分析通常都是加分项。1.3 时间分配一份卷子90分钟怎么安排如果按90到120分钟来算我一般建议这样分配选择题和填空控制在20到25分钟手写SQL留30分钟简答和场景题留35到40分钟。选择题靠“第一直觉”快速过不会的标记一下不要恋战。手写SQL是很多人丢分最严重的地方。笔试不像在IDE里写代码没有自动补全也没有执行结果提示。你写完之后要自己在脑子里过一遍执行顺序FROM、WHERE、GROUP BY、HAVING、SELECT、ORDER BY、LIMIT。一旦这个顺序没理清很容易把条件放到错的位置。简答题和场景题一定要留足时间。很多同学前面SQL写得太久最后场景题只能写三行字这是最亏的。场景题不需要长篇大论但必须把链路讲完整现象、影响范围、定位手段、临时恢复、长期方案。这个框架后面我会专门展开。2. SQL与表设计题写对是及格写好才是加分项2.1 三种必练的手写SQL套路校招笔试里的SQL题看起来变化多端实际上核心套路就三套多表关联统计、分组聚合过滤、窗口函数排行。这三个套路吃透大部分SQL题都能拆解。第一类是多表关联统计。最常见的是“统计每个用户的充值总金额和充值次数”。简单一点就直接GROUP BY难一点会加时间条件、状态条件、多表过滤。比如SELECT u.user_id, COUNT(o.order_id) AS pay_cnt, SUM(o.amount) AS total_amount FROM user_info u LEFT JOIN recharge_order o ON u.user_id o.user_id AND o.pay_time 2020-01-01 AND o.pay_time 2020-02-01 AND o.status success WHERE u.reg_time 2020-01-01 GROUP BY u.user_id ORDER BY total_amount DESC LIMIT 10;这里要注意一个细节LEFT JOIN时如果Join条件里加过滤条件要放到ON后面而不是WHERE后面。放到WHERE里会把LEFT JOIN退化成INNER JOIN这是笔试里最常见的坑。第二类是分组聚合过滤。核心是理解GROUP BY和HAVING的执行顺序。GROUP BY先分组HAVING对分组后的结果过滤WHERE是分组前的行级过滤。例如“找出充值次数大于等于3的玩家”先按user_id分组再用HAVING COUNT() 3过滤。不要写成WHERE COUNT() 3这是语法错误。第三类是窗口函数排行。2020年那会儿窗口函数已经开始频繁出现在校招笔试题里了尤其是ROW_NUMBER()、RANK()、DENSE_RANK()的区别。典型的题目是“每个支付渠道下充值金额前三的用户”SELECT channel, user_id, total_amount, rk FROM ( SELECT channel, user_id, SUM(amount) AS total_amount, ROW_NUMBER() OVER (PARTITION BY channel ORDER BY SUM(amount) DESC) AS rk FROM recharge_order WHERE status success GROUP BY channel, user_id ) t WHERE rk 3;记住窗口函数和GROUP BY的关系窗口函数在分组后的结果集上计算不会减少行数。分组用GROUP BY组内排序用OVER(PARTITION BY... ORDER BY...)。考试时如果能主动用窗口函数完成一个复杂查询通常比纯靠子查询硬套的印象分高不少。2.2 索引题别只答一句“加索引”索引相关题目在选择题、简答、SQL优化中出现频率极高。最常见的错误答案是看到查询慢就写“给查询字段加索引”。这句话在笔试里几乎等于没答。你要先搞清楚索引底层是B树不是二叉树也不是哈希表。B树的非叶子节点只存索引键叶子节点存数据或者指向数据的指针所以它适合范围查询和排序。哈希索引能O(1)精确匹配但不适合范围查询。MySQL默认InnoDB引擎用的就是B树。考察最密集的点是联合索引的最左前缀原则。假设一张表有联合索引(status, create_time)那么用它查statuscreate_time组合可以用索引只查status也能用但只查create_time就用不上。回答时最好能给出执行计划里的表现Extra里面出现Using index condition说明有索引下推Using where则可能是在回表后过滤Using filesort说明排序没用上索引。常见的失分点我整理了一张表题目描述常见错误答案更好的回答查询很慢怎么处理加索引先用EXPLAIN看执行计划判断是否全表扫描、扫描行数、是否回表、排序是否走索引索引越加越多好吗多建索引快索引会拖慢写入占用空间需要权衡查询和写入比例为什么联合索引顺序有讲究没想过最左前缀原则区分度高、查询频繁的字段放前面主键用自增还是UUID随便自增可减少页分裂UUID随机写入会造成索引页频繁分裂分库分表场景另说还有两个进阶概念值得准备覆盖索引和索引下推。覆盖索引指查询的字段已经全部包含在索引里不需要回表索引下推是MySQL 5.6以后的能力能在索引遍历过程中先过滤部分条件减少回表次数。这些概念只要在简答题里提一句就能明显看出你是有实际经验的。2.3 表设计题怎么答才像懂业务笔试里偶尔会出现“设计一张表”的题比如“请设计玩家背包表”。很多人习惯只写出字段名和类型就结束了这不够。一个有经验的DBA会把约束、索引、扩展性一起考虑进去。一个相对完整的作答思路是先列核心字段再补状态和时间字段然后考虑唯一键和索引最后说明并发和扩展时的处理。比如背包表可以这样设计CREATE TABLE player_bag ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, player_id BIGINT UNSIGNED NOT NULL, item_id INT UNSIGNED NOT NULL, item_count INT UNSIGNED NOT NULL DEFAULT 1, slot_index INT UNSIGNED NOT NULL, source VARCHAR(64) NOT NULL DEFAULT , create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_player_slot(player_id, slot_index), KEY idx_player_item(player_id, item_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里要注意几个点为什么用player_idslot_index做唯一键而不是单纯id因为玩家背包的“格子”在业务上要保证唯一防止两个道具堆到同一个格子里。为什么还要建(player_id, item_id)的索引因为高频查询是“这个玩家有哪些物品”“某物品数量多少”用这个索引可以快速定位。表设计题也要考虑分类存储。玩家背包通常属于高频热数据但玩家的历史邮件、登录日志属于冷数据可以分表甚至归档到数据仓库。笔试里把这些拆分思路写上等于告诉出题人你做过真实项目而不是只会背《数据库设计》的理论。3. 事务、锁和死锁原理题的核心拉分区3.1 隔离级别和MVCC的底层关系事务隔离级别几乎是必考题但很多同学只背了四个名字读未提交、读已提交、可重复读、串行化。笔试如果只这样答最多拿一半分。真正的问题是这四个级别分别解决什么问题MySQL默认用的是哪一级为什么选它我习惯用一张异常现象表来讲清楚隔离级别脏读不可重复读幻读READ UNCOMMITTED可能可能可能READ COMMITTED不会可能可能REPEATABLE READ不会不会可能InnoDB下不会SERIALIZABLE不会不会不会MySQL InnoDB默认是REPEATABLE READ。理论上这个级别会存在幻读但InnoDB通过间隙锁和MVCC多版本并发控制把幻读也解决了所以它可以在可重复读级别下达到接近串行化的一致性同时保留更高的并发性能。MVCC是理解隔离级别的关键。每行数据除了业务字段还有隐藏的版本字段修改时通过undo log保留旧版本。一个事务开启时会根据隔离级别生成一份ReadView。READ COMMITTED是每次SELECT都生成新的ReadView所以其他事务提交后能看到新数据REPEATABLE READ是事务第一次SELECT时生成ReadView之后复用同一份所以事务内看到的数据是快照一致的。面试官如果追问“快照读和当前读有什么区别”你要能答出来普通SELECT是快照读不加锁UPDATE、DELETE、INSERT以及SELECT ... FOR UPDATE / LOCK IN SHARE MODE是当前读要加锁。这是后续理解死锁的基础。3.2 一道死锁题的完整现场还原数据库死锁是笔试和面试都爱考的点而且往往结合业务场景。最典型的场景是充值发货和库存扣减同时发生。假设有两张表order表和item表。系统A先向order表插入订单再更新item表扣库存系统B先更新item表扣库存再向order表插入订单。两个事务交错执行就会出现一个等对方释放锁的环触发死锁。可以用下面的SQL模拟恢复现场-- 事务A BEGIN; INSERT INTO t_order(order_id, user_id, item_id) VALUES(1001, 10001, 501); UPDATE t_item SET stock stock - 1 WHERE item_id 501; COMMIT; -- 事务B BEGIN; UPDATE t_item SET stock stock - 1 WHERE item_id 501; INSERT INTO t_order(order_id, user_id, item_id) VALUES(1002, 10002, 501); COMMIT;如果A执行完INSERT还没提交B对item_id501这一行先拿到了X锁A再去更新同一行时就可能阻塞反过来B也可能在等待A持有的锁。两个事务互相等待就死锁了。InnoDB检测到死锁会回滚其中一个事务并抛出Deadlock found错误。回答这类题目光会说“死锁是循环等待”不够要给出真正能落地的方案。我通常按优先级说三条第一固定加锁顺序。所有事务都先操作item表再操作order表破坏循环等待条件。这是最治本的方法。第二缩小事务范围。把可能耗时的外部调用移出事务避免事务内做网络请求减少加锁时间。第三用乐观锁替代悲观锁。比如给item表加version字段更新时带上version条件更新影响行数为0就重试或报错。如果能再把InnoDB的间隙锁、下一键锁Next-Key Lock解释一遍说明你对原理的理解已经超过大多数校招候选人了。间隙锁锁的是索引记录之间的“间隙”主要目的就是在REPEATABLE READ下防幻读但也正是它容易导致并发场景下的死锁。3.3 连接池和连接风暴容易被忽略的必考知识点数据库题目里有一类特别容易被忽略就是连接池和连接数配置。笔试会问“数据库连接池大小到底怎么配置”“数据库突然连接不上了怎么办”。这类题看着像运维其实考的是对数据库资源模型的理解。每个数据库连接都要占用内存和文件描述符连接数不是越大越好。连接池太小高并发时SQL排队连接池太大数据库负担反而上升。HikariCP文档里给过一个启发式建议最大连接数粗略按CPU核数乘以2来估算机械硬盘环境再考虑磁盘IO并发的因素。实际项目里还要结合池内单个连接的执行时间、QPS、单连接并发能力来调。笔试如果问你“数据库突然出现大量连接超时”一般可以从这几个方向答查连接数是否达到max_connections上限看超配情况查慢SQL是否把连接池占满连接被长时间持有查是否有应用端未释放连接连接泄漏查数据库cpu、磁盘、内存是否被打满临时提高连接池上限或max_connections但不能只靠调参要找到根因。把这些方向答全其实就是在呈现一个DBA面对线上故障时的排查思路先看资源、再看SQL、最后看代码。这种思维比背任何配置项都值钱。4. 备份、复制和高可用运维题的大本营4.1 备份恢复题不能只看命令要看RPO和RTO备份恢复是数据库管理工程师和普通后端开发区别最明显的地方。后端开发可能只需要知道“有备份”就够了DBA必须把“怎么备份”“怎么恢复”“多久能恢复”讲清楚。笔试里常见的问法是“数据库误删了怎么办”或者“某时点数据损坏如何恢复”。首先要把几个备份概念区分开全量备份、增量备份、差异备份、binlog/归档日志备份。增量备份是以上一次备份为基础差异备份是以最近一次全量备份为基础。恢复时全量备份决定基础数据日志备份决定最多能恢复到哪一秒。备份类型恢复方式RPO典型工具全量备份直接用备份文件恢复取决于备份频率mysqldump、xtrabackup增量备份按顺序叠加增量比全量备份短xtrabackup --incrementalbinlog日志解析并重放SQL秒级mysqlbinlog快照备份挂载快照分钟级云厂商快照、LVM快照一道我印象很深的典型题是周一0点全量备份之后每小时做一次增量备份binlog每5分钟刷一次。周三上午10点23分误删了一张表怎么恢复解题链路应该是先恢复周三0点前最近的一次全量备份再按时间顺序应用增量备份最后用mysqlbinlog解析从增量备份结束点到10点23分之前的binlog增量跳过误删那条语句把数据恢复到误删前。答到这一步阅卷人就知道你真的处理过数据恢复。这里有个容易犯错的细节恢复前先备份当前环境避免恢复过程进一步破坏现场恢复时要把binlog中误操作的SQL识别出来并过滤掉而不是直接把全部binlog重放一遍。很多意外事故是恢复时把错误操作又执行了一遍这个教训我在工作中见过不止一次。4.2 主从复制与读写分离高频题不能只会配主从主从复制几乎是DBA笔试必考。MySQL主从复制的核心是binlog主库把变更写入binlog从库的IO线程拉取binlog并写入relay logSQL线程再重放relay log。所以binlog格式很重要statement格式可能因为SQL函数执行结果不一致导致主从数据不一致row格式记录的是行变更更安全。回答时最好提一句“生产环境推荐binlog_formatrow”。从MySQL 5.6开始有GTID每个事务都有全局事务标识符主从切换后可以自动定位到正确的位置不用手工指定binlog文件名和位置。这个知识点在笔试里很好用提出来就能和只会配传统主从的同学拉开差距。主从复制除了MySQL不同数据库各有对应方案。PostgreSQL用物理流复制Oracle用Data Guard国内常见的达梦、人大金仓也有类似的主备机制。如果笔试有开放题问“你了解哪些数据库”能说出几种生态的不同做法会显得知识面比较宽。比如Oracle Data Guard支持最大保护、最大可用、最大性能三种模式本质上是在RPO和数据可用性之间做选择和MySQL的半同步复制思想很接近。读写分离是主从复制的典型应用但作答时要说清楚一个坑主从同步永远有延迟如果不做任何处理刚写入主库的数据马上从从库读可能查不到。游戏运营后台尤其常见运营刚配置完一个活动配置立刻去页面预览结果读到旧数据这种问题要和开发确认“刚写入的数据能否接受短时间不一致”。如果要求强一致读写分离可能并不合适。4.3 高可用方案选择题怎么答高可用题往往是压轴开放题比如“如果让你给游戏运营后台设计MySQL高可用你选什么方案”。这类题考察的不是你掌握了多复杂的工具而是你会不会根据业务要求做取舍。可以先画一条线先说业务要求再说技术选型。业务要求就是两句话能容忍丢失多少数据RPO能容忍宕机多久RTO。如果RPO必须是0那主库写入至少要有半同步复制或者同步复制如果RTO只要分钟级用主从加自动切换就够如果RTO要求秒级且可以自动切换可能要引入MGR或者云数据库高可用方案。方案自动切换RPORTO适用场景主从手动切换否可能有少量丢失分钟级甚至更久允许人工介入keepalived虚IP是可能丢失30秒到分钟级后端服务能快速重连MHA是通常秒级以内10秒到30秒经典MySQL高可用MGR/PXC是接近0秒级数据一致性要求高答题时不要只说选哪个要解释为什么不选另一个。比如“不选MHA是因为需要额外部署MHA Manager节点也有脑裂风险选MGR则要评估多节点写入带来的冲突和延迟”。这种对比分析才是开放题真正想看到的。5. 场景题与故障排查题最考“拆问题”的能力5.1 排行榜和热点数据场景怎么设计游戏公司笔试题里经常出现排行榜、在线人数、热点道具这类高并发场景。这类题表面是“设计一个排行榜”实际上在考你数据库适合持久化不适合扛超高并发读。正确答案的第一步就是把请求挡在数据库前面。最经典的解法是排行数据用Redis的有序集合ZSet维护member是玩家IDscore是排行分数读写都走Redis定时或异步把排名结果持久化到MySQL。查询Top100直接读Redis的ZREVRANGEO(logN)级别的复杂度比SQL的ORDER BY快几个数量级。榜单结束后再把最终结果归档到数据库方便活动结算和查询历史榜单。答题时如果能主动提到“写回数据库的时机要兜底”会显得很懂工程。比如Redis宕机会丢一部分内存数据所以同一份排行数据最好在MySQL落一份明细Redis只做加速层活动期间每天凌晨同步一次保证即使Redis重启也能从数据库重建。如果在现在的语境下做延展这类题目还会延伸到时序数据库和向量数据库。比如监控玩家在线指标、服务性能指标适合用时序数据库做相似物品推荐、语义搜索可能用到向量数据库。但2020年的校招笔试里这些作为超纲题出现的概率不高能提一句说明你视野广没提也不丢分。5.2 一道“充值不到账”的完整排查链路场景题经常以线上故障的形式出现比如“玩家反馈充值后道具没有到账让你排查”。这道题没有标准答案但考察的是排查链路是否完整。我建议所有准备数据库岗的同学都能完整讲一遍这样的案例。我的排查链路一般是这样第一步先定位影响范围。是一个玩家、一部分玩家还是全服影响范围直接决定优先级和排查路径。如果只有一个玩家大概率是单个订单的问题如果是全服可能是数据库或消息队列的全局故障。第二步查订单和支付回调日志。充值不到账最常见的原因不是数据库挂了而是支付回调没有正确处理。在充值时通常会先生成一条待支付订单支付平台回调后更新订单状态再发货。拿到玩家订单号去查回调日志看回调是不是没到或者到了但处理失败了。第三步检查数据库侧的状态。如果回调已经成功更新订单为已支付但道具没发出去问题大概率在发货环节。用show processlist看有没有长事务和锁等待用show engine innodb status看事务和死锁信息。很多时候是更新玩家背包表时被锁阻塞事务迟迟没提交消息队列里发货任务一直在等待。mysql SHOW PROCESSLIST; mysql SHOW ENGINE INNODB STATUS\G第四步看消息队列的消费情况。游戏发货通常异步化订单系统把“发货消息”丢到MQ由发货服务消费。如果消费者停了、消费报错、或者消息积压就会出现订单已支付但道具没到账。重点看队列积压量、消费失败原因、有没有重试机制。第五步查数据一致性。如果上面都正常就需要对比订单系统的发货记录和玩家背包里的实际物品记录。常见问题是同一个支付回调被重复消费但因为缺少幂等判断业务上给玩家发了两次货或者两次更新互相覆盖。完整的回答应该包含临时措施和长期方案。临时措施是手工补发道具或者重推消息长期方案是增加回调处理的幂等表、对订单加唯一键约束、提高发货消息消费的监控告警。这种“止损、定位、根因、改善”的结构是我见过阅卷人最认可的答题节奏。5.3 场景设计题的通用答题框架场景题一旦跳出具体故障变成“让你设计一个系统”时很多人会慌。其实这类题有个通用框架先划定边界再拆需求最后落到技术选型。我给自己定过一个四步框架先问清关键指标数据量多大读写比多少是否要求强一致可容忍的故障时间是多少。校招笔试没法真的提问所以要学会“假设”并写出来再做容量估算每天产生多少订单峰值QPS大概是多少数据保留多久估算出MySQL要扛多少写入量Redis要扛多少读流量然后做存储选型核心订单数据用MySQL缓存用Redis需要全文检索或日志分析再引入对应组件避免在一个方案里堆太多技术栈最后补充高可用和监控数据库主从、备份策略、慢SQL监控、连接数告警、死锁告警这些都是DBA视角下不能少的闭环。比如“设计一个游戏邮件系统”很多人第一反应是直接建一张表存所有玩家的邮件。但如果你按上面的框架想就会发现全服邮件和单人邮件应该分开设计全服邮件只存一份配置玩家登录时动态读取单人邮件才需要给每个玩家生成一条记录。表设计也不是简单建索引就能完事还要考虑上限数量、过期清理、已读状态更新频率这些细节。这个思考过程比最终的表结构更重要。6. 备考方法和复盘心得短期提分最有效的几件事6.1 校招笔试里最常见的三种丢分方式我帮学弟复盘过好几套数据库笔试题发现丢分点高度集中基本可以归成三类。第一类是手写SQL的边界条件缺失。比如统计充值金额时忘记过滤statussuccess或者LEFT JOIN的过滤条件放到WHERE导致数据少了。SQL题不是写出来就能满分阅卷人会看逻辑是否严谨所以平时练习就要养成把条件写全的习惯。第二类是原理题只写结论不写过程。比如问“为什么用B树不用红黑树”只回答“B树矮”是不够的。要答出“B树非叶子节点不存数据一页能存储更多键值树高更低磁盘IO更少叶子节点用链表串联范围查询方便”。笔试题目越开放越要展示你的推导过程。第三类是场景题没有落地点。很多同学能写出“加缓存、加索引、做主从”这种泛泛方案但说不清加哪张表的索引、缓存和数据库怎么保持一致性、主从切换后应用如何重连。这类回答在阅卷人眼里等于没答。宁可方案少一点也要把每一个方案说透。6.2 结合2020年前后的技术栈做针对性准备既然是复盘搜狐畅游2020校招就不能脱离那个时间点的技术环境。2020年正是MySQL 5.7普及、8.0开始被讨论的阶段Redis 5和6占了主流很多游戏公司还在用Kafka做日志和异步消息。准备的时候不要把注意力全放在最新技术上把MySQL和Redis的地基打牢收益远大于追新。同时国产数据库和替代性方案在这个阶段的讨论也变多了。像达梦、人大金仓、GaussDB这类产品如果题目里出现了通常不是考产品细节而是问“它们和MySQL/Oracle的兼容性”“你如何评估迁移”。遇到这类题建议从SQL兼容性、事务隔离级别、备份恢复机制、周边生态几个角度来答不要陷入某个具体命令的背诵。另外2020年之后的几年里向量数据库、云原生数据库、Serverless数据库都很火但在校招笔试里这些更多是面试聊天的加分话题基础核心仍然是关系型数据库的SQL、索引、事务、锁、备份恢复。把这些考点自己梳理成一份知识地图比碎片化刷面经有效得多。6.3 三个马上能落地的准备动作如果你现在离笔试还有两三周我最建议做这三件事。第一每天手写五道SQL不要用IDE。练习时限定自己在纸上或纯文本里写强制自己记住语法和函数名。重点练多表JOIN、LEFT JOIN与INNER JOIN的区别、GROUP BY与HAVING、窗口函数、子查询嵌套。第二自己本地搭一套MySQL环境把死锁、锁等待、事务隔离级别的例子跑一遍。跑完后用show engine innodb status看锁信息然后总结一套自己的话术。这道题在笔试面试里出现概率太高亲自跑一遍比背十遍原理都管用。第三准备一个能完整讲述的故障案例。不用多一个就够了。可以是自己处理过的问题也可以是经典案例如充值不到账、数据库连接打满、主从延迟过高。关键是按“现象、定位、恢复、根因、预防”的逻辑讲顺讲到任何一步都能给出具体命令或数据指标。这个能力在场景题和面试环节都是直接转化的分数。我自己带过的人里面凡是笔试前老老实实把这三件事做一遍的最后数据库方向的笔试成绩都不差。这套方法也不局限在搜狐畅游几乎所有游戏公司和互联网公司的数据库岗位都可以复用。题目会变出题人想看到的思维习惯不会变。 数据库管理工程师笔试复盘：从SQL优化到高可用核心考点
前阵子有个学弟准备秋招翻出一份搜狐畅游2020校招数据库管理工程师的笔试回忆题来问我选择题还能对付手写SQL一紧张就想不起来场景题更不知道怎么下笔。我把这套题的核心考点按DBA日常工作的逻辑重新拆了一遍发现它其实不是死记硬背就能过的更像是把“数据库工程师平时怎么排查问题”压缩在一张卷子里。这篇文章就按我的复盘顺序来写先讲卷子结构再拆高频考点最后给场景题的答题框架。适合正在准备数据库岗校招、或者刚工作想补一轮数据库基础的人看。1. 卷子结构和考察意图出题人想要什么样的人1.1 一张数据库管理工程师笔试试卷的常见拼图互联网公司的校招笔试尤其是数据库管理方向题型通常不会太偏大体上由选择题、填空题、手写SQL、简答题和场景题组成。搜狐畅游这套卷子内部虽然不一定每年完全一样但从我接触过的同类题目来看分布大概是这样的题型大致题量/分值考察重点单选/多选20题左右占20分基础概念、参数、Linux命令、网络协议填空10题左右占10分术语定义、默认配置、端口、目录路径手写SQL3到4题占30分多表关联、聚合、分组、窗口函数、索引优化简答2题左右占20分事务、锁、隔离级别、备份恢复、主从复制场景设计/故障排查1到2题占20分架构选型、问题定位链路、业务理解这个结构很典型。前60分其实是在筛“基础扎不扎实”后面的40分才是真正拉开差距的地方。很多同学复习时喜欢抱着《数据库系统概论》背范式、背E-R图但实际笔试里关系代数出现概率极低反而SQL和运维场景占了大头。这一点要先有心理预期。另外一个容易被忽略的地方是笔试题里会出现不少“看起来是数据库题实际在考Linux和网络”的题目。比如问MySQL的默认端口、Redis的持久化配置、查看慢日志的常用命令、TCP三次握手和连接池的关系。这些都不是纯数据库原理而是日常运维必须碰的东西。游戏公司的DBA要跟账号服、充值服、区服运维打交道不会这些基本功笔试和面试都很难过。1.2 游戏业务里的数据库岗位到底做什么为什么游戏公司校招数据库管理工程师要考SQL和场景题而不是死板的理论因为游戏业务的数据库场景太典型了。一个最普通的游戏后台至少要支撑这几块账号系统用户注册、登录、token失效、角色系统角色属性、背包、装备、充值订单系统订单创建、支付回调、发货入账、运营活动系统活动配置、排行榜、邮件、日志统计系统玩家行为、充值流水、服务器监控。这些模块对数据库的要求不太一样账号和订单要求强一致背包和角色允许短时间内缓存延迟排行榜要求高并发读日志则是持续写入。笔试里那些看似零散的考点其实就是这些业务场景在纸面上的投影。比如考事务和死锁多半是为了应对“同一玩家同时充值并发货”这类并发问题考主从复制和备份恢复是为了提醒你游戏服可能半夜出故障你不能让全服玩家干等考索引优化是因为一条慢SQL打在充值表上整个区服都会卡。所以你在答题时不要把每个知识点孤立地背要能主动说清楚“这个方案能解决什么问题”“在什么业务场景下会用到”。哪怕题目没有明确要求简答题里主动带上场景分析通常都是加分项。1.3 时间分配一份卷子90分钟怎么安排如果按90到120分钟来算我一般建议这样分配选择题和填空控制在20到25分钟手写SQL留30分钟简答和场景题留35到40分钟。选择题靠“第一直觉”快速过不会的标记一下不要恋战。手写SQL是很多人丢分最严重的地方。笔试不像在IDE里写代码没有自动补全也没有执行结果提示。你写完之后要自己在脑子里过一遍执行顺序FROM、WHERE、GROUP BY、HAVING、SELECT、ORDER BY、LIMIT。一旦这个顺序没理清很容易把条件放到错的位置。简答题和场景题一定要留足时间。很多同学前面SQL写得太久最后场景题只能写三行字这是最亏的。场景题不需要长篇大论但必须把链路讲完整现象、影响范围、定位手段、临时恢复、长期方案。这个框架后面我会专门展开。2. SQL与表设计题写对是及格写好才是加分项2.1 三种必练的手写SQL套路校招笔试里的SQL题看起来变化多端实际上核心套路就三套多表关联统计、分组聚合过滤、窗口函数排行。这三个套路吃透大部分SQL题都能拆解。第一类是多表关联统计。最常见的是“统计每个用户的充值总金额和充值次数”。简单一点就直接GROUP BY难一点会加时间条件、状态条件、多表过滤。比如SELECT u.user_id, COUNT(o.order_id) AS pay_cnt, SUM(o.amount) AS total_amount FROM user_info u LEFT JOIN recharge_order o ON u.user_id o.user_id AND o.pay_time 2020-01-01 AND o.pay_time 2020-02-01 AND o.status success WHERE u.reg_time 2020-01-01 GROUP BY u.user_id ORDER BY total_amount DESC LIMIT 10;这里要注意一个细节LEFT JOIN时如果Join条件里加过滤条件要放到ON后面而不是WHERE后面。放到WHERE里会把LEFT JOIN退化成INNER JOIN这是笔试里最常见的坑。第二类是分组聚合过滤。核心是理解GROUP BY和HAVING的执行顺序。GROUP BY先分组HAVING对分组后的结果过滤WHERE是分组前的行级过滤。例如“找出充值次数大于等于3的玩家”先按user_id分组再用HAVING COUNT() 3过滤。不要写成WHERE COUNT() 3这是语法错误。第三类是窗口函数排行。2020年那会儿窗口函数已经开始频繁出现在校招笔试题里了尤其是ROW_NUMBER()、RANK()、DENSE_RANK()的区别。典型的题目是“每个支付渠道下充值金额前三的用户”SELECT channel, user_id, total_amount, rk FROM ( SELECT channel, user_id, SUM(amount) AS total_amount, ROW_NUMBER() OVER (PARTITION BY channel ORDER BY SUM(amount) DESC) AS rk FROM recharge_order WHERE status success GROUP BY channel, user_id ) t WHERE rk 3;记住窗口函数和GROUP BY的关系窗口函数在分组后的结果集上计算不会减少行数。分组用GROUP BY组内排序用OVER(PARTITION BY... ORDER BY...)。考试时如果能主动用窗口函数完成一个复杂查询通常比纯靠子查询硬套的印象分高不少。2.2 索引题别只答一句“加索引”索引相关题目在选择题、简答、SQL优化中出现频率极高。最常见的错误答案是看到查询慢就写“给查询字段加索引”。这句话在笔试里几乎等于没答。你要先搞清楚索引底层是B树不是二叉树也不是哈希表。B树的非叶子节点只存索引键叶子节点存数据或者指向数据的指针所以它适合范围查询和排序。哈希索引能O(1)精确匹配但不适合范围查询。MySQL默认InnoDB引擎用的就是B树。考察最密集的点是联合索引的最左前缀原则。假设一张表有联合索引(status, create_time)那么用它查statuscreate_time组合可以用索引只查status也能用但只查create_time就用不上。回答时最好能给出执行计划里的表现Extra里面出现Using index condition说明有索引下推Using where则可能是在回表后过滤Using filesort说明排序没用上索引。常见的失分点我整理了一张表题目描述常见错误答案更好的回答查询很慢怎么处理加索引先用EXPLAIN看执行计划判断是否全表扫描、扫描行数、是否回表、排序是否走索引索引越加越多好吗多建索引快索引会拖慢写入占用空间需要权衡查询和写入比例为什么联合索引顺序有讲究没想过最左前缀原则区分度高、查询频繁的字段放前面主键用自增还是UUID随便自增可减少页分裂UUID随机写入会造成索引页频繁分裂分库分表场景另说还有两个进阶概念值得准备覆盖索引和索引下推。覆盖索引指查询的字段已经全部包含在索引里不需要回表索引下推是MySQL 5.6以后的能力能在索引遍历过程中先过滤部分条件减少回表次数。这些概念只要在简答题里提一句就能明显看出你是有实际经验的。2.3 表设计题怎么答才像懂业务笔试里偶尔会出现“设计一张表”的题比如“请设计玩家背包表”。很多人习惯只写出字段名和类型就结束了这不够。一个有经验的DBA会把约束、索引、扩展性一起考虑进去。一个相对完整的作答思路是先列核心字段再补状态和时间字段然后考虑唯一键和索引最后说明并发和扩展时的处理。比如背包表可以这样设计CREATE TABLE player_bag ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, player_id BIGINT UNSIGNED NOT NULL, item_id INT UNSIGNED NOT NULL, item_count INT UNSIGNED NOT NULL DEFAULT 1, slot_index INT UNSIGNED NOT NULL, source VARCHAR(64) NOT NULL DEFAULT , create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_player_slot(player_id, slot_index), KEY idx_player_item(player_id, item_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里要注意几个点为什么用player_idslot_index做唯一键而不是单纯id因为玩家背包的“格子”在业务上要保证唯一防止两个道具堆到同一个格子里。为什么还要建(player_id, item_id)的索引因为高频查询是“这个玩家有哪些物品”“某物品数量多少”用这个索引可以快速定位。表设计题也要考虑分类存储。玩家背包通常属于高频热数据但玩家的历史邮件、登录日志属于冷数据可以分表甚至归档到数据仓库。笔试里把这些拆分思路写上等于告诉出题人你做过真实项目而不是只会背《数据库设计》的理论。3. 事务、锁和死锁原理题的核心拉分区3.1 隔离级别和MVCC的底层关系事务隔离级别几乎是必考题但很多同学只背了四个名字读未提交、读已提交、可重复读、串行化。笔试如果只这样答最多拿一半分。真正的问题是这四个级别分别解决什么问题MySQL默认用的是哪一级为什么选它我习惯用一张异常现象表来讲清楚隔离级别脏读不可重复读幻读READ UNCOMMITTED可能可能可能READ COMMITTED不会可能可能REPEATABLE READ不会不会可能InnoDB下不会SERIALIZABLE不会不会不会MySQL InnoDB默认是REPEATABLE READ。理论上这个级别会存在幻读但InnoDB通过间隙锁和MVCC多版本并发控制把幻读也解决了所以它可以在可重复读级别下达到接近串行化的一致性同时保留更高的并发性能。MVCC是理解隔离级别的关键。每行数据除了业务字段还有隐藏的版本字段修改时通过undo log保留旧版本。一个事务开启时会根据隔离级别生成一份ReadView。READ COMMITTED是每次SELECT都生成新的ReadView所以其他事务提交后能看到新数据REPEATABLE READ是事务第一次SELECT时生成ReadView之后复用同一份所以事务内看到的数据是快照一致的。面试官如果追问“快照读和当前读有什么区别”你要能答出来普通SELECT是快照读不加锁UPDATE、DELETE、INSERT以及SELECT ... FOR UPDATE / LOCK IN SHARE MODE是当前读要加锁。这是后续理解死锁的基础。3.2 一道死锁题的完整现场还原数据库死锁是笔试和面试都爱考的点而且往往结合业务场景。最典型的场景是充值发货和库存扣减同时发生。假设有两张表order表和item表。系统A先向order表插入订单再更新item表扣库存系统B先更新item表扣库存再向order表插入订单。两个事务交错执行就会出现一个等对方释放锁的环触发死锁。可以用下面的SQL模拟恢复现场-- 事务A BEGIN; INSERT INTO t_order(order_id, user_id, item_id) VALUES(1001, 10001, 501); UPDATE t_item SET stock stock - 1 WHERE item_id 501; COMMIT; -- 事务B BEGIN; UPDATE t_item SET stock stock - 1 WHERE item_id 501; INSERT INTO t_order(order_id, user_id, item_id) VALUES(1002, 10002, 501); COMMIT;如果A执行完INSERT还没提交B对item_id501这一行先拿到了X锁A再去更新同一行时就可能阻塞反过来B也可能在等待A持有的锁。两个事务互相等待就死锁了。InnoDB检测到死锁会回滚其中一个事务并抛出Deadlock found错误。回答这类题目光会说“死锁是循环等待”不够要给出真正能落地的方案。我通常按优先级说三条第一固定加锁顺序。所有事务都先操作item表再操作order表破坏循环等待条件。这是最治本的方法。第二缩小事务范围。把可能耗时的外部调用移出事务避免事务内做网络请求减少加锁时间。第三用乐观锁替代悲观锁。比如给item表加version字段更新时带上version条件更新影响行数为0就重试或报错。如果能再把InnoDB的间隙锁、下一键锁Next-Key Lock解释一遍说明你对原理的理解已经超过大多数校招候选人了。间隙锁锁的是索引记录之间的“间隙”主要目的就是在REPEATABLE READ下防幻读但也正是它容易导致并发场景下的死锁。3.3 连接池和连接风暴容易被忽略的必考知识点数据库题目里有一类特别容易被忽略就是连接池和连接数配置。笔试会问“数据库连接池大小到底怎么配置”“数据库突然连接不上了怎么办”。这类题看着像运维其实考的是对数据库资源模型的理解。每个数据库连接都要占用内存和文件描述符连接数不是越大越好。连接池太小高并发时SQL排队连接池太大数据库负担反而上升。HikariCP文档里给过一个启发式建议最大连接数粗略按CPU核数乘以2来估算机械硬盘环境再考虑磁盘IO并发的因素。实际项目里还要结合池内单个连接的执行时间、QPS、单连接并发能力来调。笔试如果问你“数据库突然出现大量连接超时”一般可以从这几个方向答查连接数是否达到max_connections上限看超配情况查慢SQL是否把连接池占满连接被长时间持有查是否有应用端未释放连接连接泄漏查数据库cpu、磁盘、内存是否被打满临时提高连接池上限或max_connections但不能只靠调参要找到根因。把这些方向答全其实就是在呈现一个DBA面对线上故障时的排查思路先看资源、再看SQL、最后看代码。这种思维比背任何配置项都值钱。4. 备份、复制和高可用运维题的大本营4.1 备份恢复题不能只看命令要看RPO和RTO备份恢复是数据库管理工程师和普通后端开发区别最明显的地方。后端开发可能只需要知道“有备份”就够了DBA必须把“怎么备份”“怎么恢复”“多久能恢复”讲清楚。笔试里常见的问法是“数据库误删了怎么办”或者“某时点数据损坏如何恢复”。首先要把几个备份概念区分开全量备份、增量备份、差异备份、binlog/归档日志备份。增量备份是以上一次备份为基础差异备份是以最近一次全量备份为基础。恢复时全量备份决定基础数据日志备份决定最多能恢复到哪一秒。备份类型恢复方式RPO典型工具全量备份直接用备份文件恢复取决于备份频率mysqldump、xtrabackup增量备份按顺序叠加增量比全量备份短xtrabackup --incrementalbinlog日志解析并重放SQL秒级mysqlbinlog快照备份挂载快照分钟级云厂商快照、LVM快照一道我印象很深的典型题是周一0点全量备份之后每小时做一次增量备份binlog每5分钟刷一次。周三上午10点23分误删了一张表怎么恢复解题链路应该是先恢复周三0点前最近的一次全量备份再按时间顺序应用增量备份最后用mysqlbinlog解析从增量备份结束点到10点23分之前的binlog增量跳过误删那条语句把数据恢复到误删前。答到这一步阅卷人就知道你真的处理过数据恢复。这里有个容易犯错的细节恢复前先备份当前环境避免恢复过程进一步破坏现场恢复时要把binlog中误操作的SQL识别出来并过滤掉而不是直接把全部binlog重放一遍。很多意外事故是恢复时把错误操作又执行了一遍这个教训我在工作中见过不止一次。4.2 主从复制与读写分离高频题不能只会配主从主从复制几乎是DBA笔试必考。MySQL主从复制的核心是binlog主库把变更写入binlog从库的IO线程拉取binlog并写入relay logSQL线程再重放relay log。所以binlog格式很重要statement格式可能因为SQL函数执行结果不一致导致主从数据不一致row格式记录的是行变更更安全。回答时最好提一句“生产环境推荐binlog_formatrow”。从MySQL 5.6开始有GTID每个事务都有全局事务标识符主从切换后可以自动定位到正确的位置不用手工指定binlog文件名和位置。这个知识点在笔试里很好用提出来就能和只会配传统主从的同学拉开差距。主从复制除了MySQL不同数据库各有对应方案。PostgreSQL用物理流复制Oracle用Data Guard国内常见的达梦、人大金仓也有类似的主备机制。如果笔试有开放题问“你了解哪些数据库”能说出几种生态的不同做法会显得知识面比较宽。比如Oracle Data Guard支持最大保护、最大可用、最大性能三种模式本质上是在RPO和数据可用性之间做选择和MySQL的半同步复制思想很接近。读写分离是主从复制的典型应用但作答时要说清楚一个坑主从同步永远有延迟如果不做任何处理刚写入主库的数据马上从从库读可能查不到。游戏运营后台尤其常见运营刚配置完一个活动配置立刻去页面预览结果读到旧数据这种问题要和开发确认“刚写入的数据能否接受短时间不一致”。如果要求强一致读写分离可能并不合适。4.3 高可用方案选择题怎么答高可用题往往是压轴开放题比如“如果让你给游戏运营后台设计MySQL高可用你选什么方案”。这类题考察的不是你掌握了多复杂的工具而是你会不会根据业务要求做取舍。可以先画一条线先说业务要求再说技术选型。业务要求就是两句话能容忍丢失多少数据RPO能容忍宕机多久RTO。如果RPO必须是0那主库写入至少要有半同步复制或者同步复制如果RTO只要分钟级用主从加自动切换就够如果RTO要求秒级且可以自动切换可能要引入MGR或者云数据库高可用方案。方案自动切换RPORTO适用场景主从手动切换否可能有少量丢失分钟级甚至更久允许人工介入keepalived虚IP是可能丢失30秒到分钟级后端服务能快速重连MHA是通常秒级以内10秒到30秒经典MySQL高可用MGR/PXC是接近0秒级数据一致性要求高答题时不要只说选哪个要解释为什么不选另一个。比如“不选MHA是因为需要额外部署MHA Manager节点也有脑裂风险选MGR则要评估多节点写入带来的冲突和延迟”。这种对比分析才是开放题真正想看到的。5. 场景题与故障排查题最考“拆问题”的能力5.1 排行榜和热点数据场景怎么设计游戏公司笔试题里经常出现排行榜、在线人数、热点道具这类高并发场景。这类题表面是“设计一个排行榜”实际上在考你数据库适合持久化不适合扛超高并发读。正确答案的第一步就是把请求挡在数据库前面。最经典的解法是排行数据用Redis的有序集合ZSet维护member是玩家IDscore是排行分数读写都走Redis定时或异步把排名结果持久化到MySQL。查询Top100直接读Redis的ZREVRANGEO(logN)级别的复杂度比SQL的ORDER BY快几个数量级。榜单结束后再把最终结果归档到数据库方便活动结算和查询历史榜单。答题时如果能主动提到“写回数据库的时机要兜底”会显得很懂工程。比如Redis宕机会丢一部分内存数据所以同一份排行数据最好在MySQL落一份明细Redis只做加速层活动期间每天凌晨同步一次保证即使Redis重启也能从数据库重建。如果在现在的语境下做延展这类题目还会延伸到时序数据库和向量数据库。比如监控玩家在线指标、服务性能指标适合用时序数据库做相似物品推荐、语义搜索可能用到向量数据库。但2020年的校招笔试里这些作为超纲题出现的概率不高能提一句说明你视野广没提也不丢分。5.2 一道“充值不到账”的完整排查链路场景题经常以线上故障的形式出现比如“玩家反馈充值后道具没有到账让你排查”。这道题没有标准答案但考察的是排查链路是否完整。我建议所有准备数据库岗的同学都能完整讲一遍这样的案例。我的排查链路一般是这样第一步先定位影响范围。是一个玩家、一部分玩家还是全服影响范围直接决定优先级和排查路径。如果只有一个玩家大概率是单个订单的问题如果是全服可能是数据库或消息队列的全局故障。第二步查订单和支付回调日志。充值不到账最常见的原因不是数据库挂了而是支付回调没有正确处理。在充值时通常会先生成一条待支付订单支付平台回调后更新订单状态再发货。拿到玩家订单号去查回调日志看回调是不是没到或者到了但处理失败了。第三步检查数据库侧的状态。如果回调已经成功更新订单为已支付但道具没发出去问题大概率在发货环节。用show processlist看有没有长事务和锁等待用show engine innodb status看事务和死锁信息。很多时候是更新玩家背包表时被锁阻塞事务迟迟没提交消息队列里发货任务一直在等待。mysql SHOW PROCESSLIST; mysql SHOW ENGINE INNODB STATUS\G第四步看消息队列的消费情况。游戏发货通常异步化订单系统把“发货消息”丢到MQ由发货服务消费。如果消费者停了、消费报错、或者消息积压就会出现订单已支付但道具没到账。重点看队列积压量、消费失败原因、有没有重试机制。第五步查数据一致性。如果上面都正常就需要对比订单系统的发货记录和玩家背包里的实际物品记录。常见问题是同一个支付回调被重复消费但因为缺少幂等判断业务上给玩家发了两次货或者两次更新互相覆盖。完整的回答应该包含临时措施和长期方案。临时措施是手工补发道具或者重推消息长期方案是增加回调处理的幂等表、对订单加唯一键约束、提高发货消息消费的监控告警。这种“止损、定位、根因、改善”的结构是我见过阅卷人最认可的答题节奏。5.3 场景设计题的通用答题框架场景题一旦跳出具体故障变成“让你设计一个系统”时很多人会慌。其实这类题有个通用框架先划定边界再拆需求最后落到技术选型。我给自己定过一个四步框架先问清关键指标数据量多大读写比多少是否要求强一致可容忍的故障时间是多少。校招笔试没法真的提问所以要学会“假设”并写出来再做容量估算每天产生多少订单峰值QPS大概是多少数据保留多久估算出MySQL要扛多少写入量Redis要扛多少读流量然后做存储选型核心订单数据用MySQL缓存用Redis需要全文检索或日志分析再引入对应组件避免在一个方案里堆太多技术栈最后补充高可用和监控数据库主从、备份策略、慢SQL监控、连接数告警、死锁告警这些都是DBA视角下不能少的闭环。比如“设计一个游戏邮件系统”很多人第一反应是直接建一张表存所有玩家的邮件。但如果你按上面的框架想就会发现全服邮件和单人邮件应该分开设计全服邮件只存一份配置玩家登录时动态读取单人邮件才需要给每个玩家生成一条记录。表设计也不是简单建索引就能完事还要考虑上限数量、过期清理、已读状态更新频率这些细节。这个思考过程比最终的表结构更重要。6. 备考方法和复盘心得短期提分最有效的几件事6.1 校招笔试里最常见的三种丢分方式我帮学弟复盘过好几套数据库笔试题发现丢分点高度集中基本可以归成三类。第一类是手写SQL的边界条件缺失。比如统计充值金额时忘记过滤statussuccess或者LEFT JOIN的过滤条件放到WHERE导致数据少了。SQL题不是写出来就能满分阅卷人会看逻辑是否严谨所以平时练习就要养成把条件写全的习惯。第二类是原理题只写结论不写过程。比如问“为什么用B树不用红黑树”只回答“B树矮”是不够的。要答出“B树非叶子节点不存数据一页能存储更多键值树高更低磁盘IO更少叶子节点用链表串联范围查询方便”。笔试题目越开放越要展示你的推导过程。第三类是场景题没有落地点。很多同学能写出“加缓存、加索引、做主从”这种泛泛方案但说不清加哪张表的索引、缓存和数据库怎么保持一致性、主从切换后应用如何重连。这类回答在阅卷人眼里等于没答。宁可方案少一点也要把每一个方案说透。6.2 结合2020年前后的技术栈做针对性准备既然是复盘搜狐畅游2020校招就不能脱离那个时间点的技术环境。2020年正是MySQL 5.7普及、8.0开始被讨论的阶段Redis 5和6占了主流很多游戏公司还在用Kafka做日志和异步消息。准备的时候不要把注意力全放在最新技术上把MySQL和Redis的地基打牢收益远大于追新。同时国产数据库和替代性方案在这个阶段的讨论也变多了。像达梦、人大金仓、GaussDB这类产品如果题目里出现了通常不是考产品细节而是问“它们和MySQL/Oracle的兼容性”“你如何评估迁移”。遇到这类题建议从SQL兼容性、事务隔离级别、备份恢复机制、周边生态几个角度来答不要陷入某个具体命令的背诵。另外2020年之后的几年里向量数据库、云原生数据库、Serverless数据库都很火但在校招笔试里这些更多是面试聊天的加分话题基础核心仍然是关系型数据库的SQL、索引、事务、锁、备份恢复。把这些考点自己梳理成一份知识地图比碎片化刷面经有效得多。6.3 三个马上能落地的准备动作如果你现在离笔试还有两三周我最建议做这三件事。第一每天手写五道SQL不要用IDE。练习时限定自己在纸上或纯文本里写强制自己记住语法和函数名。重点练多表JOIN、LEFT JOIN与INNER JOIN的区别、GROUP BY与HAVING、窗口函数、子查询嵌套。第二自己本地搭一套MySQL环境把死锁、锁等待、事务隔离级别的例子跑一遍。跑完后用show engine innodb status看锁信息然后总结一套自己的话术。这道题在笔试面试里出现概率太高亲自跑一遍比背十遍原理都管用。第三准备一个能完整讲述的故障案例。不用多一个就够了。可以是自己处理过的问题也可以是经典案例如充值不到账、数据库连接打满、主从延迟过高。关键是按“现象、定位、恢复、根因、预防”的逻辑讲顺讲到任何一步都能给出具体命令或数据指标。这个能力在场景题和面试环节都是直接转化的分数。我自己带过的人里面凡是笔试前老老实实把这三件事做一遍的最后数据库方向的笔试成绩都不差。这套方法也不局限在搜狐畅游几乎所有游戏公司和互联网公司的数据库岗位都可以复用。题目会变出题人想看到的思维习惯不会变。