企业官网建设流程全解析

前阵子有个学弟准备秋招，翻出一份搜狐畅游2020校招数据库管理工程师的笔试回忆题来问我：选择题还能对付，手写SQL一紧张就想不起来，场景题更不知道怎么下笔。我把这套题的核心考点按DBA日常工作的逻辑重新拆了一遍，发现它其实不是死记硬背就能过的，更像是把“数据库工程师平时怎么排查问题”压缩在一张卷子里。这篇文章就按我的复盘顺序来写：先讲卷子结构，再拆高频考点，最后给场景题的答题框架。适合正在准备数据库岗校招、或者刚工作想补一轮数据库基础的人看。

1. 卷子结构和考察意图：出题人想要什么样的人

1.1 一张数据库管理工程师笔试试卷的常见拼图

互联网公司的校招笔试，尤其是数据库管理方向，题型通常不会太偏，大体上由选择题、填空题、手写SQL、简答题和场景题组成。搜狐畅游这套卷子内部虽然不一定每年完全一样，但从我接触过的同类题目来看，分布大概是这样的：

这个结构很典型。前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)，那么用它查status+create_time组合可以用索引，只查status也能用，但只查create_time就用不上。回答时最好能给出执行计划里的表现：Extra里面出现Using index condition说明有索引下推，Using where则可能是在回表后过滤，Using filesort说明排序没用上索引。

常见的失分点我整理了一张表：

还有两个进阶概念值得准备：覆盖索引和索引下推。覆盖索引指查询的字段已经全部包含在索引里，不需要回表；索引下推是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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里要注意几个点：为什么用player_id+slot_index做唯一键，而不是单纯id？因为玩家背包的“格子”在业务上要保证唯一，防止两个道具堆到同一个格子里。为什么还要建(player_id, item_id)的索引？因为高频查询是“这个玩家有哪些物品”“某物品数量多少”，用这个索引可以快速定位。

表设计题也要考虑分类存储。玩家背包通常属于高频热数据，但玩家的历史邮件、登录日志属于冷数据，可以分表甚至归档到数据仓库。笔试里把这些拆分思路写上，等于告诉出题人你做过真实项目，而不是只会背《数据库设计》的理论。

3. 事务、锁和死锁：原理题的核心拉分区

3.1 隔离级别和MVCC的底层关系

事务隔离级别几乎是必考题，但很多同学只背了四个名字：读未提交、读已提交、可重复读、串行化。笔试如果只这样答，最多拿一半分。真正的问题是：这四个级别分别解决什么问题？MySQL默认用的是哪一级？为什么选它？

我习惯用一张异常现象表来讲清楚：

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_id=501这一行先拿到了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/归档日志备份。增量备份是以上一次备份为基础，差异备份是以最近一次全量备份为基础。恢复时，全量备份决定基础数据，日志备份决定最多能恢复到哪一秒。

一道我印象很深的典型题是：周一0点全量备份，之后每小时做一次增量备份，binlog每5分钟刷一次。周三上午10点23分误删了一张表，怎么恢复？

解题链路应该是：先恢复周三0点前最近的一次全量备份，再按时间顺序应用增量备份，最后用mysqlbinlog解析从增量备份结束点到10点23分之前的binlog增量，跳过误删那条语句，把数据恢复到误删前。答到这一步，阅卷人就知道你真的处理过数据恢复。

这里有个容易犯错的细节：恢复前先备份当前环境，避免恢复过程进一步破坏现场；恢复时要把binlog中误操作的SQL识别出来并过滤掉，而不是直接把全部binlog重放一遍。很多意外事故是恢复时把错误操作又执行了一遍，这个教训我在工作中见过不止一次。

4.2 主从复制与读写分离：高频题不能只会配主从

主从复制几乎是DBA笔试必考。MySQL主从复制的核心是binlog：主库把变更写入binlog，从库的IO线程拉取binlog并写入relay log，SQL线程再重放relay log。所以binlog格式很重要，statement格式可能因为SQL函数执行结果不一致导致主从数据不一致，row格式记录的是行变更，更安全。回答时最好提一句“生产环境推荐binlog_format=row”。

从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或者云数据库高可用方案。

答题时不要只说选哪个，要解释为什么不选另一个。比如“不选MHA是因为需要额外部署MHA Manager节点，也有脑裂风险；选MGR则要评估多节点写入带来的冲突和延迟”。这种对比分析才是开放题真正想看到的。

5. 场景题与故障排查题：最考“拆问题”的能力

5.1 排行榜和热点数据场景怎么设计

游戏公司笔试题里经常出现排行榜、在线人数、热点道具这类高并发场景。这类题表面是“设计一个排行榜”，实际上在考你：数据库适合持久化，不适合扛超高并发读。正确答案的第一步就是把请求挡在数据库前面。

最经典的解法是：排行数据用Redis的有序集合（ZSet）维护，member是玩家ID，score是排行分数，读写都走Redis，定时或异步把排名结果持久化到MySQL。查询Top100直接读Redis的ZREVRANGE，O(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的边界条件缺失。比如统计充值金额时忘记过滤status='success'，或者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看锁信息，然后总结一套自己的话术。这道题在笔试面试里出现概率太高，亲自跑一遍比背十遍原理都管用。

第三，准备一个能完整讲述的故障案例。不用多，一个就够了。可以是自己处理过的问题，也可以是经典案例如充值不到账、数据库连接打满、主从延迟过高。关键是按“现象、定位、恢复、根因、预防”的逻辑讲顺，讲到任何一步都能给出具体命令或数据指标。这个能力在场景题和面试环节都是直接转化的分数。

我自己带过的人里面，凡是笔试前老老实实把这三件事做一遍的，最后数据库方向的笔试成绩都不差。这套方法也不局限在搜狐畅游，几乎所有游戏公司和互联网公司的数据库岗位都可以复用。题目会变，出题人想看到的思维习惯不会变。