浩鲸科技2020届数据库A卷这份卷子在校招圈里流传挺广的。浩鲸科技前身是中兴软创主要做电信运营商BSS/OSS系统数据库技术栈以Oracle和MySQL为主业务场景里全是高并发计费、海量话单、实时出账这些硬骨头。所以它的数据库笔试题不像互联网公司那样偏重缓存、消息队列而是扎扎实实考关系型数据库的基本功——事务、索引、SQL优化、数据库设计。我当年刷过这套题后来也帮学弟学妹做过几次复盘今天把这份卷子背后的考点和备考逻辑完整拆一遍希望对准备校招数据库岗的同学有实际帮助。这份卷子适合谁看一是正在准备运营商系、通信软件系公司校招的应届生二是想检验自己数据库基本功是否扎实的初中级开发三是准备跳槽想系统性复习数据库核心知识的朋友。整个卷面如果我没记错大致是选择题、填空题、SQL编写题、数据库设计题和简答题五大部分篇幅不小两个小时内要写完其实挺紧张的。下面按题型逐块拆。1. 试卷全局复盘这套题到底在考察什么1.1 题型分布与考察逻辑浩鲸科技这份数据库A卷整体题型分布和很多通信软件公司的校招笔试题高度相似核心逻辑就一句话在有限时间内筛出那些真正写过SQL、真正理解数据库底层原理的人而不是靠背题海混进来的应试者。先看选择题覆盖面比较广从关系代数、范式理论、事务隔离级别到索引结构都有涉及。其中事务隔离级别和索引这两块几乎是必考而且往往不止一道题。填空题则偏爱考SQL标准函数、数据库系统基本概念比如ACID四个特性的英文全称、GROUP BY的执行顺序这类细节。SQL编写题是整张卷子的重头戏一般给两三张业务表要求写出特定查询涉及多表关联、聚合函数、子查询和窗口函数。数据库设计题会给你一个mini业务场景要求设计表结构并写出建表SQL可能附带索引设计。最后的简答题通常考察优化思路比如慢查询排查、索引失效场景、分库分表策略等。从考察逻辑来看这套题强调的是一名数据库方向工程师入职后最基础也最核心的能力能不能看懂业务表结构能不能写出正确且高效的SQL能不能在两三个字段之间设计出合理的表和索引。通信行业的业务系统数据量动辄上亿还有实时性要求所以对SQL效率和索引设计尤为看重。备考时如果只是刷LeetCode数据库题其实不够还得把数据库原理教材里的基础概念吃透尤其是事务、锁、索引这三座大山。1.2 每类题型的“潜台词”与备考侧重不同题型其实对应着公司对不同能力维度的考察这里展开说一下每类题型背后的潜台词。选择题和填空题的潜台词是基础理论是否系统。浩鲸科技做的电信BSS系统对数据一致性要求极高出账、扣费、余额变动这些操作一旦出错就是生产事故所以候选人必须对事务的ACID、隔离级别、锁机制有清晰认知。备考时建议把《数据库系统概论》里的事务章节和索引章节反复啃尤其是隔离级别和锁的兼容矩阵这些考点选择题里换个说法就很容易踩坑。SQL编写题的潜台词是能不能直接上手干活。通信行业有大量报表统计需求比如话单量汇总、用户消费排行、业务增长趋势都是典型的多表关联加分组聚合场景。这类题没有捷径就是多写把各种JOIN的语义差异、GROUP BY的执行逻辑、窗口函数的使用场景练熟。我见过不少同学理论知识很扎实一上手写SQL就露怯就是因为平时练习量不够。数据库设计题的潜台词是有没有工程思维。不是让你背范式定义而是给你一个业务场景看你能不能把实体、属性、关系梳理清楚能不能合理设置主键外键能不能在数据冗余和查询效率之间做权衡。备考时多拿实际业务练手比如设计一个电商订单系统、设计一个员工考勤系统写完整的设计文档再建表。简答题的潜台词则是遇到线上问题有没有排查思路。慢查询怎么定位、索引为什么不生效、死锁怎么解决这类题必须结合生产实践来答光背书上的概念拿不到高分。2. 必考知识点深度拆解事务、索引、锁、范式2.1 事务ACID与隔离级别不只是背概念事务这块浩鲸科技的笔试题尤其重视隔离级别。为什么因为通信计费系统是典型的高并发读写场景同一个用户的余额可能同时被多个请求修改如果隔离级别设置不当要么出现脏读要么锁冲突严重。你要理解不同隔离级别到底解决了什么问题、引入了什么问题不能只背四个级别名称和对应的英文单词。隔离级别从低到高依次是读未提交、读已提交、可重复读、串行化。读未提交允许脏读业务上基本不用读已提交解决了脏读但可能出现不可重复读Oracle默认就是这一级可重复读解决了不可重复读MySQL默认这一级但存在幻读问题串行化最严格但也最慢。笔试中常见的考察方式是给出一个并发事务执行时序让你判断在某个隔离级别下会读到什么结果。还有一个高频考点是MVCC多版本并发控制。MySQL的InnoDB引擎就是通过MVCC加间隙锁来实现可重复读隔离级别的它让读操作不阻塞写操作、写操作不阻塞读操作大幅提升并发性能。理解MVCC的关键是理解隐藏列、undo log和ReadView机制——每行数据有两个隐藏列分别记录创建版本号和删除版本号事务读取时根据ReadView判断当前版本是否可见。这块如果能讲清楚简答题基本就能拿高分。2.2 索引原理与失效场景SQL优化的地基索引相关知识点在浩鲸科技的卷子里也是重头戏选择题、简答题都可能出现。最基础的考察点是B树索引结构为什么MySQL用B树而不是B树或哈希索引。因为B树所有数据都存储在叶子节点并且叶子节点之间用指针连接非常适合范围查询和排序而哈希索引只能做等值匹配无法用于范围查询。更进阶的考点是联合索引和最左前缀原则面试官或试卷喜欢通过一个具体SQL让你判断索引是否生效。最左前缀原则的意思是联合索引(a,b,c)相当于创建了(a)、(a,b)、(a,b,c)三个索引查询条件里如果缺少最左列a整个索引就无法使用。比如WHERE b1 AND c2因为条件里没有a索引失效走全表扫描。索引失效的常见场景几乎是必考内容对索引列使用函数或计算导致索引失效比如WHERE YEAR(create_time)2024隐式类型转换导致索引失效比如字符串列不用引号LIKE以通配符开头导致索引失效使用OR连接非索引列导致索引失效负向查询IN (NOT IN)、EXISTS (NOT EXISTS)也可能导致索引失效具体要看数据分布。备考时建议把这些场景整理成一张速查表每个场景配一个示例SQL方便考前快速回顾。2.3 锁机制与死锁从原理到实战锁这块的考察点浩鲸科技偏务实。除了考锁的类型分类更爱考死锁的产生条件和排查思路因为电信系统并发高死锁是躲不开的问题。数据库锁可以按粒度分为表锁和行锁按模式分为共享锁和排他锁。InnoDB的行锁是建立在索引之上的如果SQL没有走索引行锁会升级为表锁这是笔试中非常爱挖的坑。死锁产生的四个必要条件必须掌握互斥、持有并等待、不可剥夺、循环等待。考试中一般给一个两事务互相持有对方所需资源的SQL场景让分析是否死锁以及如何解决。实际工作中排查死锁的方法也要能写出来通过SHOW ENGINE INNODB STATUS查看最近一次死锁信息分析事务等待的资源链检查业务代码中多个SQL的加锁顺序是否一致考虑降低隔离级别或改用乐观锁。生产环境表结构复杂加上分库分表之后锁的粒度会更细分析起来也更复杂但笔试阶段能说清原理和基本排查思路就够用。2.4 三大范式与反范式设计如何权衡范式是数据库设计题的理论支撑选择题也常考。第一范式要求字段原子性不可再分第二范式要求非主键字段完全依赖于主键不能只依赖主键的一部分第三范式要求非主键字段不能传递依赖于主键。这三条要能结合具体表结构判断是否满足。但光知道范式定义不够浩鲸科技这种业务复杂度高的公司更看重你在实际设计中的权衡能力。完全遵循第三范式查询时就要join很多张表性能可能很差适当冗余一些字段是电信行业表设计的常用手段。比如用户订单表里冗余一个用户名虽然违反第三范式但可以避免每次查询都join用户表。笔试做设计题时建议先按第三范式设计基础表结构然后在查询频繁的路径上有意识地加一些冗余字段并说明这样做的理由面试官会觉得你有工程经验。3. SQL实操题考场还原典型题型的解题套路3.1 多表关联查询分清INNER JOIN和LEFT JOIN浩鲸科技SQL题最喜欢出的场景就是“学生选课成绩”这套经典模型或者通信行业常见的“用户-套餐-账单”模型。不管场景怎么变核心考察点都是JOIN的语义理解。INNER JOIN只返回两表匹配的行LEFT JOIN返回左表全部行加右表匹配行右表无匹配则补NULL。看起来简单但做题时经常有人搞混。举个例子题目给两张表学生表student(id, name, class_id)、选课表course_selection(student_id, course_name, score)要求查询每个学生的选课数量没选课的学生也要显示。一眼就该知道用LEFT JOIN因为“没选课的学生也要显示”这个条件决定了必须保留左表全部行。正确写法SELECT s.id, s.name, COUNT(cs.course_name) AS course_count FROM student s LEFT JOIN course_selection cs ON s.id cs.student_id GROUP BY s.id, s.name;注意COUNT(cs.course_name)而不是COUNT()因为COUNT()会把右表为NULL的行也计数进去导致没选课的学生课程数量显示为1。这是一个非常经典的坑几乎每年面试都有同学踩。答题时一定要关注这种边界细节比如COUNT是否要排除NULL、是否需要DISTINCT去重。3.2 聚合统计与分组过滤HAVING的用法聚合函数的考察最常见的坑是WHERE和HAVING的区别。WHERE在分组前过滤行HAVING在分组后过滤组。写SQL时如果过滤条件涉及聚合结果必须放HAVING比如查询平均分大于80分的班级。但纯行级别的过滤条件比如“只看2023年入学的学生”放在WHERE里效率更高因为先过滤再分组可以减少分组的数据量。再一个高频考点是GROUP BY的使用规范。MySQL有一个比较坑的地方在ONLY_FULL_GROUP_BY模式下SELECT后面出现的非聚合列必须出现在GROUP BY中否则报错。很多同学在这个地方翻车。例如上面的学生选课数查询如果写成SELECT s.name, COUNT(cs.course_name) FROM ... GROUP BY s.id在默认sql_mode下能跑出结果但换到ONLY_FULL_GROUP_BY就会报错。笔试答题时建议把GROUP BY的字段写全既符合规范又不容易出错。窗口函数也是近年考题的热点。比如查每个班级成绩排名前3的学生用窗口函数一行搞定SELECT * FROM ( SELECT s.name, c.class_name, cs.score, ROW_NUMBER() OVER (PARTITION BY c.id ORDER BY cs.score DESC) AS rn FROM student s JOIN class c ON s.class_id c.id JOIN course_selection cs ON s.id cs.student_id ) t WHERE rn 3;窗口函数这道题的关键是理解PARTITION BY和ORDER BY在窗口函数中的含义。PARTITION BY决定窗口的分组范围ORDER BY决定组内排序方式ROW_NUMBER()按顺序分配1、2、3...号。如果是并列排名应该用RANK()或DENSE_RANK()而不是ROW_NUMBER()这一点也能体现候选人对业务语义的理解深度。3.3 增删改查的边界处理与数据一致性不要以为增删改查就不考了。浩鲸科技这类公司反而很看重DML语句的严谨性因为生产环境的INSERT、UPDATE不是随便写的。笔试中可能考UPDATE多表关联比如根据订单明细更新订单汇总表的金额也可能考DELETE与JOIN的组合使用。这类题目的核心是数据一致性。举例来说删除课程成绩数据时如果课程表和学生表存在外键约束直接删除父表数据会被拒绝。答题时要考虑使用级联删除或在删除前先处理子表数据。另一个常见场景是批量更新比如给某个班级所有学生的成绩加5分可以用UPDATE student JOIN course_selection ON ... SET score score 5 WHERE class_id ?MySQL支持这种语法但Oracle中不能这样写需要用MERGE INTO或者子查询实现。笔试如果没注明数据库类型建议默认按MySQL处理但最好在答案里注明环境。还有一个容易被忽视的点是事务的显式控制。笔试如果要求“将多条SQL作为一个原子操作”一定要记得加START TRANSACTION和COMMIT/ROLLBACK并说明为什么需要事务——保证数据要么全部提交要么全部回滚。这个细节看似简单但能体现候选人是否有生产环境的数据一致性意识简答题中说一句“我用事务包裹保证一致性”就是加分项。4. 数据库设计题实战从需求分析到建表SQL4.1 需求分析先识别实体、属性和关系浩鲸科技的数据库设计题通常给一段业务描述比如“设计一个电信套餐管理系统的数据库要求支持用户管理、套餐订购、账单查询”然后让你设计表结构、写出建表语句可能还要设计索引。这类题第一步不是写SQL而是梳理业务逻辑。先把核心实体识别出来用户、套餐、订单/账单。再确定实体间关系一个用户可以订购多个套餐一个套餐可以被多个用户订购这是典型的多对多关系需要一张中间表来关联。用户和账单是一对多关系因为一个用户有多个账单记录。属性也要逐一定义比如用户表要包含哪些字段、套餐表要包含哪些字段、账单表要包含哪些字段。这里推荐先画一个简单的ER图草稿哪怕不画图也要在脑子里把关系理清楚否则表设计出来容易逻辑混乱。我见过很多同学拿到设计题直接就开始CREATE TABLE写到一半发现缺字段或者关系没体现又回头改既浪费时间又降低答题质量。先花5分钟梳理实体关系远比直接动手写SQL更高效。4.2 表结构设计与建表SQL字段类型、主键、外键、索引表结构设计的核心是每个字段的精确定义。字段类型的选择要考虑业务场景用户ID用BIGINT还是VARCHAR创建时间用DATETIME还是TIMESTAMP金额字段用DECIMAL而不是FLOAT。DECIMAL处理精确小数FLOAT是浮点数会丢失精度做金额计算时必须用DECIMAL这是做设计题的一个送分点。主键和外键的设置也要合理。电信系统的表通常用自增ID或雪花ID做主键账单表里则用订单号作为唯一业务键。外键约束在实际生产环境往往不建而是靠应用层保证因为外键会影响写入性能、增加锁竞争。但笔试答题时建议在表结构中体现外键关系可以在建表时用FOREIGN KEY关键字也可以在注释里说明该字段是逻辑外键。两种做法都能得分关键是让人看懂你理解了表间关系。在设计索引时不要给每个字段都加索引而是要考虑实际查询场景。比如账单表最频繁的查询条件通常是“查某个用户某个月的账单”那联合索引(user_id, bill_month)就是合理的如果还经常按账单状态筛选可以加一个状态字段的索引或者设计更复杂的联合索引。笔试时能写清楚“为什么建这个索引、对应什么查询场景”比堆一堆索引名称更有价值。4.3 冗余字段与性能权衡设计题拿高分的关键设计题想拿高分需要在满足范式的基础上体现性能思维。一个常见做法是在主表里冗余一些统计字段比如用户表里冗余一个套餐数量或者套餐表里冗余一个订购人数。这些字段可以通过触发器或应用层来维护但能显著减少高频查询的JOIN次数。另一个思路是设计台账表或流水表。电信计费场景中账单表通常很大按用户ID和时间做分区是常见手段。笔试设计题如果允许可以在表设计中加入分区策略比如按月份分区这样能大幅提升查询效率。设计题出现这种思路面试官会认为你有实际项目经验而不只是会背课本。最后是数据字典和字段注释。设计题的答题纸如果空间允许建议给每张表写简要说明给关键字段加COMMENT。比如用户表的status字段注明1表示正常、0表示停用这样阅卷人一眼就能看出你对业务状态流转的理解。细节决定成败多花三分钟写注释回报率极高。5. 答题节奏与避坑指南来自过来人的经验5.1 时间分配建议先做SQL和设计题再回头啃选择题浩鲸科技这份A卷题量不小如果按顺序从头做到尾很容易在选择题上卡住导致后面的SQL大题和设计题没时间写。我的建议是拿到卷子先花两分钟整体浏览一遍然后优先做SQL编写题和数据库设计题。这两类题分值高、区分度大而且只要思路清晰、SQL语法正确拿分确定性很强。选择题和填空题里如果遇到拿不准的先标记跳过最后再回来慢慢琢磨。做SQL题时我习惯先在草稿纸上把表结构和数据关系梳理清楚再用SQL实现。写完之后花10秒检查一遍JOIN、GROUP BY、HAVING、窗口函数的写法尤其是“是否存在右表为NULL的情况”“COUNT是否应该用DISTINCT”这些边界细节。整体算下来时间分配大约是选择题和填空题30分钟SQL题40分钟设计题30分钟简答题20分钟留10分钟检查。5.2 高频扣分点这些坑我见过太多人踩先说选择题的经典坑。第一事务隔离级别和锁的兼容矩阵容易混淆建议考前把脏读、不可重复读、幻读三个问题的定义反复理解而不是死背。第二索引失效场景的题目喜欢把条件写成WHERE name LIKE %张或WHERE DATE(create_time)...这种形式识别出“对索引列使用函数或前导通配符”就基本能锁定答案。第三范式判断题里传递依赖的识别容易出错比如“学号→系别→系主任”这个链路明显是传递依赖不满足第三范式。SQL题的扣分点主要集中在三处一是COUNT和COUNT(列名)的语义混淆二是GROUP BY字段不全导致在ONLY_FULL_GROUP_BY模式下报错三是LEFT JOIN和INNER JOIN选错导致数据行数不对。设计题的扣分点则是字段类型不合理、主外键缺失、没有考虑索引场景。这些扣分点都不是难度问题而是细心程度问题考前把这些点过一遍就能大幅提分。5.3 面试延伸笔试题和简历项目怎么联动浩鲸科技的笔试考完之后如果进入面试面试官很可能会顺着笔试卷子里的SQL题或设计题继续追问比如“你写的这条SQL在数据量大时的性能如何优化”“你设计的表如果上线后遇到慢查询怎么办”。所以笔试结束后建议把卷子里的SQL题重新梳理一遍想一想每条SQL的优化空间这在面试环节会很有优势。简历项目也要和笔试题呼应。如果你在项目里做过订单系统就把订单表的设计、索引方案、可能遇到的慢查询优化准备充分面试官问到设计题时直接引用项目经验比空谈理论更有说服力。我在帮学弟做模拟面试时发现能把笔试题目和项目实际场景联系起来讲的候选人录取概率明显高于只答理论的人。6. 常见问题与实战排查慢查询、索引失效、死锁速查表笔试简答题喜欢出“如何处理生产环境慢查询”这类问题其实就是考察你有没有真实排障经验。我把常见场景整理成一张速查表不管是笔试答题还是实际工作都能用上。问题现象排查思路常用命令/手段某个SQL执行特别慢先看执行计划确认是否全表扫描、是否命中索引EXPLAIN SELECT ...索引未生效检查是否有隐式类型转换、函数运算、前导通配符SHOW INDEX FROM table; 对比字段类型行锁升级为表锁查看SQL是否通过索引条件更新或删除SHOW ENGINE INNODB STATUS数据库CPU飙升查慢查询日志抓出TOP N慢SQL开启slow_query_logmysqldumpslow分析死锁发生查看最近死锁信息分析事务加锁顺序SHOW ENGINE INNODB STATUS检查事务获取锁的先后顺序大表查询慢考虑分区表、分库分表、读写分离ALTER TABLE ... PARTITION BY RANGE这些问题在浩鲸科技的简答题、面试题中出现的概率非常高。尤其是执行计划相关的EXPLAIN答这道题时建议说明关注哪些列type列是否出现ALL全表扫描、possible_keys和key列是否一致、rows列是否扫描了大量行。如果能在答案里提到“通过覆盖索引避免回表”含金量会明显提升。死锁问题的解答也要避免空泛。背出四个必要条件还不够要能加上实际排查步骤第一步看错误日志里的死锁SQL第二步还原事务的加锁时序第三步在代码层面统一事务的加锁顺序第四步考虑缩小事务范围或缩短持有锁的时间。这样答才既完整又接地气。关于数据库优化还有一个常规但重要的点不要一上来就谈分库分表。很多候选人回答优化问题时张口就是分库分表、引入中间件好像很高级但实际业务中绝大多数性能问题都是通过索引优化、SQL改写、缓存来解决的。答优化题时先谈SQL改写和索引优化再谈缓存最后才是分库分表这个思路更符合生产环境的排障逻辑。7. 一些实在的建议说回到浩鲸科技这份2020届数据库A卷它的整体风格是“基础但不简单”考的全是数据库工程师日常工作中最常用的知识但每个点都往里挖了一层。准备这类校招笔试最忌讳的就是只看面经不刷题、只看概念不写SQL。我个人的经验是考前两周把《数据库系统概论》的重点章节过一遍然后每天保持10到20道SQL的练习量把JOIN、聚合、窗口函数、索引优化这些题型练成本能反应考试时才不会慌。另一个小技巧是做设计题的时候把自己想象成真的要给这个系统建表的老工程师而不是做题的学生。想想这个表上线后每天会有多少数据写入、查询热点是什么、字段会不会变更按工程标准去设计分数自然就上去了。最后祝准备校招的同学都能顺利拿下心仪的offer数据库这条路上基本功扎实的人永远不吃亏。