拓冰网站定制 
每年到了七八月份秋招的战线就陆陆续续拉开了。数据库岗作为后端技术栈里非常吃底子的方向笔试题目往往不像前端、客户端那样考一堆框架用法而是扎扎实实考你对数据模型、事务并发、索引原理的理解深度。我参加了2023年度小满秋招数据库岗的第一批笔试整套题做下来最大的感受是它不是在考你背了多少知识点而是在考你有没有真正动手处理过线上问题有没有在夜深人静的时候盯着一个慢查询日志发过呆。这篇文章就围绕这批笔试的完整复盘展开从题型分布到每个模块的核心考点再到我自己踩过的坑一次性梳理清楚。无论是马上要参加后续批次笔试的同学还是准备明年秋招的在校生应该都能从中获得一些可复用的备考思路。1. 这次笔试的总体情况与出题风格1.1 笔试形式与考察范围概览先说整体情况。小满秋招数据库岗的第一批笔试是线上限时作答时长120分钟题量不算特别大但每道题都需要认真思考。整体分为四类题型单选题、多选题、简答题、手写SQL与方案设计题。单选和多选覆盖的是数据库基础理论比如事务隔离级别、索引失效场景、日志机制这些简答题偏向原理阐述比如让你解释MVCC的实现机制、Binlog和Redo Log的区别手写SQL和方案设计题是重头戏占分比例最高考察的是候选人能不能在限定时间内写出正确、高效、可维护的SQL以及面对一个实际业务场景时能不能设计出合理的数据模型。从考察范围来看这批笔试明显偏向MySQL生态同时穿插了不少分布式数据库、国产数据库的内容。这可能和小满自身的技术栈有关。Redis、HBase、Elasticsearch这些周边组件没有直接出大题但在选择题里出现了一些概念性的判断比如Redis持久化机制、HBase的LSM-Tree结构等等。整体来看题目设计得很克制没有偏题怪题每一道都能在常规的学习路径里找到对应出处。1.2 出题思路分析为什么这样设计我个人总结下来这套笔试题的出题风格可以用一句话概括基于真实的数据库运维和开发场景考察候选人的底层原理掌握程度和问题排查能力。举个例子单选题里有一道关于死锁的题它没有直接问“死锁的四个必要条件是什么”而是给了一个具体的并发操作序列让你判断这两个事务在什么隔离级别下会发生死锁以及MySQL检测到死锁后会选择回滚哪一个事务。这种出题方式非常考验对InnoDB锁机制的理解。如果你只是背过“互斥、持有并等待、不可剥夺、循环等待”这四个词遇到这种题基本只能靠猜。同样的简答题里让你对比Binlog和Redo Log如果只是回答“一个是逻辑日志、一个是物理日志”那只能拿到基础分。出题人想看到的是你能不能说清楚为什么MySQL需要两种日志它们各自在什么阶段产生、什么阶段发挥作用以及崩溃恢复时它们是怎么配合的。对于准备笔试的同学来说这种出题风格意味着不能只看面经和八股文需要真正去读一读官方文档甚至亲手搭一套MySQL环境做实验验证。2. SQL基本功从增删改查到复杂查询2.1 手写SQL的考点与陷阱这批笔试的手写SQL题一共有三道分布在试卷的不同部分。第一道是基础的增删改查给了一张订单表和一张用户表要求写出“查询2023年5月下单次数超过3次的用户ID和下单次数按照下单次数降序排列”这样的查询语句。虽然看起来很基础但里面埋了三个小坑时间范围过滤应该怎么写才能利用上索引、分组后过滤用HAVING还是WHERE、以及ORDER BY的排序规则。如果对时间字段的处理不当比如在WHERE里对时间列使用了函数导致索引失效就很容易被后面的附加题问住。我记得这题的第二个小问就是让你说明自己的SQL为什么能走索引这明显是在考隐式类型转换和函数操作对索引的影响。第二道题是INSERT ... ON DUPLICATE KEY UPDATE的运用。场景是每日统计报表要求把当天每个商品类别的销售额写入统计表如果当天已有记录则累加销售额。这道题除了考察写入逻辑还给了一个候选方案让你评价先查一次判断是否存在再决定INSERT还是UPDATE。这种先查后写的方式在高并发场景下存在竞态条件问题而ON DUPLICATE KEY UPDATE是原子性的通过唯一键冲突直接走更新路径。类似的做法还有REPLACE INTO但REPLACE INTO在冲突时会先删除旧记录再插入新记录如果表上有外键或者自增ID可能会引发不期望的行为。这一题很能拉开差距。2.2 窗口函数与复杂查询第三道SQL题难度明显上了一个台阶要求使用窗口函数计算“每个用户在连续下单天数中的最大连续天数”。这道题在LeetCode上能找到原型但在笔试场景下需要在没有IDE提示的情况下手写完成。窗口函数的核心思路是先用LAG或ROW_NUMBER生成每个用户订单日期的排序编号然后通过日期减去编号的差值来判断连续性。如果差值相同说明这些日期是连续的。我在考场上用的是ROW_NUMBER()配合DATE_SUB的方式WITH user_orders AS ( SELECT user_id, order_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date) AS rn FROM orders GROUP BY user_id, order_date ), diff_calc AS ( SELECT user_id, order_date, DATE_SUB(order_date, INTERVAL rn DAY) AS diff FROM user_orders ) SELECT user_id, MAX(consecutive_days) AS max_consecutive_days FROM ( SELECT user_id, COUNT(*) AS consecutive_days FROM diff_calc GROUP BY user_id, diff ) t GROUP BY user_id;这里有一个隐藏的细节同一个用户在同一天可能有多笔订单所以必须先用GROUP BY user_id, order_date去重否则窗口函数的行号会对不上。考场上很容易漏掉这一步导致整个计算结果错误。这类题考察的不只是窗口函数的语法还考察了面对真实业务数据时能不能识别出数据质量问题。2.3 写SQL时的习惯与自查清单笔试和实际工作中写SQL有一个共同的难点很难立刻知道自己的SQL是否正确。在实际工作中可以explain、可以跑测试数据验证但在笔试场景下只能靠逻辑推演。我在这批笔试中总结了一个自查清单分享给大家字段名和表名是否与题目给出的完全一致大小写和反引号是否处理正确多表连接时ON条件是否写清楚了关联字段有没有产生笛卡尔积的风险分组统计时SELECT出的非聚合字段是否都在GROUP BY中在ONLY_FULL_GROUP_BY模式下会直接报错WHERE和HAVING的过滤时机是否搞清楚能不能在WHERE阶段就过滤掉不需要的行时间字段的类型是DATETIME还是TIMESTAMP比较时是否需要考虑时区子查询的关联条件是否写对了相关子查询和非相关子查询在性能上的差异是否考虑过这张清单看起来很简单但在限定时间内能逐项自查的候选人并不多。平时练习的时候最好养成这个习惯形成肌肉记忆。3. 事务、锁与并发控制笔试里的硬骨头3.1 事务隔离级别的场景判断事务隔离级别这部分的考察是整张试卷中选择题密度最高的区域。有一道题给了四个并发执行的事务每个事务都执行了一系列读写操作让你判断在Read Committed和Repeatable Read两种隔离级别下某个SELECT语句分别会读到什么结果。这道题需要非常清晰地理解当前读和快照读的区别以及在不同隔离级别下快照的生成时机。在Read Committed级别下每次SELECT都会生成一个新的快照所以能读到其他事务已经提交的数据而在Repeatable Read级别下快照在第一次SELECT时就固定了后续的SELECT都基于这个快照即使其他事务提交了新数据也看不到。但要注意这里说的是普通SELECT快照读如果SELECT语句带上了FOR UPDATE或者LOCK IN SHARE MODE就变成了当前读读到的一定是最新已提交的数据并且会对记录加锁。这道题就是拿这两种读模式混合出题让考生判断到底读到什么、锁住什么。MVCC机制是回答这类题的基础。InnoDB的MVCC通过隐藏字段DB_TRX_ID最后修改事务ID和DB_ROLL_PTR回滚指针来实现配合undo log构建版本链。ReadView是判断版本可见性的核心里面记录了活跃事务ID列表、最小活跃事务ID、最大事务ID等关键信息。评判一条记录是否可见时规则可以总结为如果版本的事务ID小于最小活跃ID说明已经提交可见如果大于等于最大ID说明是未来事务不可见如果落在中间则需要判断该事务ID是否在活跃列表里如果在则不可见否则可见。这套规则在两种隔离级别下的差异只在于ReadView的生成时机。3.2 死锁场景分析与解决思路关于死锁的题目试卷里有足足三道分布在单选和多选中这种出题密度足以看出小满对这块的重视程度。其中一道选择题的大意是事务A先更新了表t1的id1记录再更新表t2的id2记录事务B先更新表t2的id2记录再更新表t1的id1记录。在RR隔离级别下两个事务同时执行是否会死锁如果需要解决有哪些手段这题典型考察死锁的四个必要条件互斥、持有并等待、不可剥夺、循环等待。两个事务都持有对方需要的锁同时又在等待对方释放形成了闭环所以必然死锁。解决手段可以从多个层面回答调整业务SQL的顺序让所有事务都按照相同的顺序访问表使用事务超时机制innodb_lock_wait_timeout控制等待时间InnoDB本身有死锁检测机制大约每秒检测一次发现死锁后会回滚其中一个事务通常是undo log较少、回滚代价小的事务。这里有一个容易被忽略的细节在RR级别下如果事务A先按条件更新了多条记录比如UPDATE ... WHERE status1插入了一条满足条件的记录但事务A还没有提交那么事务B插入同一条件范围的记录时会遇到间隙锁Gap Lock的阻塞而不是等到真正插入时才冲突。间隙锁锁的是索引记录之间的间隙目的是防止幻读。在RR隔离级别下InnoDB通过Next-Key Lock记录锁间隙锁的组合来解决幻读问题。这道题的陷阱就在于很多人只知道行锁忽略了间隙锁的存在导致判断失误。3.3 连接池参数与线上问题排查还有一道多选题是关于数据库连接池的给了HikariCP的几个参数maximumPoolSize、minimumIdle、connectionTimeout、idleTimeout、maxLifetime让你判断哪些参数设置不当会引发连接耗尽或连接失效问题。这道题虽然理论性不强但非常贴近实际运维场景。连接池参数设置不合理确实是生产环境最常见的故障源之一。maximumPoolSize设置太小高峰期并发一上来连接就不够用了业务侧会报“Connection is not available, request timed out”设置太大数据库端会维护大量空闲连接浪费内存而且MySQL默认的max_connections是151超出后新连接会被拒绝。minimumIdle和idleTimeout配合不当会导致连接池频繁创建和销毁连接。maxLifetime如果设置得比数据库wait_timeout还大可能会出现连接被数据库端断开但连接池不知道的情况应用拿到一个失效连接后执行SQL就会报“Connection has been closed”之类的异常。这些内容在字节、美团的面试经验里经常出现但这批笔试直接用选择题考察说明出题者希望候选人不是只懂理论而是真的关注过线上连接池告警。备考时最好把HikariCP、Druid、C3P0这几个常用连接池的参数都过一遍并理解每个参数设置背后的考量。4. 索引与执行计划从原理到优化实战4.1 索引数据结构选型与底层原理索引部分的知识点在笔试中占了很大比例。单选和多选加起来至少有六道题是关于索引的包括索引数据结构、索引失效场景、覆盖索引、索引下推等内容。其中一道题问的是为什么InnoDB选择B树而不是B树或哈希表作为索引的数据结构这道题的答题要点在于说清楚B树的几个特性。B树的非叶子节点不存储数据只存储索引键值和指向子节点的指针因此单页能承载的键值数量远大于B树树的高度更低磁盘IO次数更少。B树的所有数据都存储在叶子节点上并且叶子节点之间通过双向链表连接这让范围查询和排序操作非常高效——只需要找到范围的起点然后顺着链表向后遍历即可。哈希表虽然等值查询是O(1)的复杂度但无法支持范围查询也无法利用索引进行排序和前缀匹配。B树虽然在每个节点都存储数据但单页能容纳的键值数量少树的高度高而且范围查询需要中序遍历性能远不如B树。题目的加分项是提到InnoDB的主键索引和二级索引在叶子节点上存储的内容是不同的。主键索引的叶子节点存储完整行数据二级索引的叶子节点存储主键值所以通过二级索引查询数据时如果需要回表会先根据二级索引查出主键值再回到主键索引中定位完整记录。如果二级索引已经覆盖了查询所需的全部字段就不需要回表了这就是覆盖索引优化。4.2 索引失效的典型场景关于索引失效有一道多选题列出了五种查询条件让你判断哪些无法使用phone字段上的普通索引WHERE phone LIKE 138%WHERE SUBSTR(phone, 1, 3) 138WHERE phone 0 13812345678WHERE phone 13812345678WHERE phone IN (13812345678, 13912345678)这道题考察的是索引失效的常见原因。对索引列进行了函数操作会导致索引失效这是数据库优化器无法直接利用索引树进行范围定位的原因。对索引列进行隐式类型转换也会导致索引失效因为MySQL需要对字段进行类型转换后再比较。但LIKE 138%这种前缀匹配是可以走索引的这利用了B树的字符串排序特性。IN操作在MySQL优化器中一般会转化为多个等值条件的OR组合是可以走索引的。考场上需要注意的一个细节是隐式类型转换如果phone字段是字符串类型但查询条件是phone 13812345678数字会被转换成字符串再比较。根据MySQL的规则当字符串列和数字比较时字符串会被转换为数字这意味着需要对每一行的phone列值做一次转换索引就失效了。所以正确答案是第二个、第三个和第四个第四个需要看字段类型如果字段是字符串而参数是数字则失效。4.3 执行计划解读与慢查询定位简答题中有一道是给你一段执行计划让你说明这段SQL可能存在的性能问题并给出优化建议。执行计划中展示的关键字段包括type、key、rows、Extra这些。给出的执行计划大致是这样的type是ALL说明是全表扫描没有走到索引rows是100万说明优化器估算需要扫描100万行Extra字段中有Using filesort说明排序操作没有用到索引需要额外的文件排序。我把这道题的答案拆成三步来写第一步优先解决全表扫描问题。看WHERE条件里的字段是否适合建索引如果查询主要是等值过滤建立普通索引就够用了如果是范围查询需要评估索引选择性选择区分度高的字段作为索引的前导列。第二步解决排序问题。如果查询结果集很大并且需要排序考虑建立联合索引让排序字段包含在索引中这样优化器可以直接利用索引的有序性避免filesort。第三步控制返回的数据量。如果业务只需要前20条数据但SQL中缺少LIMIT优化器可能需要把所有满足条件的数据都找出来再排序这会造成不必要的资源消耗。执行计划这道题在笔试和实际工作中都属于高频考点。建议大家提前把explain输出中的每个字段含义好好过一遍特别是type从system到ALL的级别顺序以及Extra中Using index、Using where、Using temporary、Using filesort分别代表什么问题。5. 数据库设计与新趋势考点国产库、向量库与时序库5.1 数据库设计范式与反范式设计题部分给出了一个电商场景用户表、商品表、订单表、订单明细表、商品分类表要求设计订单查询功能的数据模型并给出核心表的字段设计和索引设计。这道题没有标准答案但阅卷者会从几个维度打分有没有合理拆分表结构、字段类型选择是否合理、索引设计是否覆盖了核心查询路径、有没有考虑数据量增长后的扩展方案。我在设计时优先满足的是三范式把订单明细和订单主表分开避免重复存储用户信息。但在商品名称这个字段上我主动做了反范式设计——在订单明细表里冗余了下单时的商品快照信息商品名称、单价、图片URL等。原因是商品信息可能会更新如果不做快照历史订单的展示就会出问题。这种方式在电商系统里非常常见也是面试中考察反范式设计优劣的经典场景。冗余带来的好处是查询订单时不需要回商品表补信息坏处是如果商品信息变化历史订单里的快照不会跟着变。这个取舍需要根据业务需求来判断。索引设计上我为核心查询路径建立了几个索引订单表以user_id create_time作为联合索引支持“我的订单”按时间倒序分页查询订单明细表以order_id建立二级索引因为查询订单明细时总是通过订单ID去关联商品表以category_id建立索引支持分类浏览。这里有一个容易忽略的点订单号本身如果是一个雪花ID或UUID那么它作为主键时在B树上的插入是随机的这会导致页分裂写入性能下降。很多生产系统会用全局ID生成器生成有序ID或者使用自增ID作为主键而订单号作为独立唯一索引。5.2 国产数据库的考察方式这批笔试中有一道关于国产数据库的题目让我印象很深。题目对比了达梦数据库和人大金仓数据库在兼容性方面的差异要求说明它们在对接MySQL或Oracle应用时各有什么优势。这其实反映了近两年国产数据库在金融、政务、电信等行业加速落地的背景秋招出题提到它们并不意外。达梦在很多场景下主打的是对Oracle的兼容包括PL/SQL语法、包、存储过程、触发器这些特性让原有的Oracle应用可以低成本地迁移过来。人大金仓的KingbaseES在兼容Oracle的同时也对PostgreSQL生态有较好的兼容性因为它的内核大量参考了PostgreSQL。题目还问到了如果从Oracle迁移到达梦需要注意哪些点。我的回答从几个方面展开数据类型映射的差异、自增序列的实现方式、存储过程的语法差异、分页查询的写法差异Oracle用ROWNUM达梦支持LIMIT、以及排序空值处理逻辑等。这个知识点看起来有一定门槛但备考时不用过于恐慌。重点还是回到数据库原理的基本面事务、锁、索引、日志。国产数据库和MySQL、Oracle在这些基本原理上是共通的差别主要体现在语法和工具链上。只要原理扎实迁移和适配的问题是可以快速学习的。5.3 向量数据库与时序数据库的考点最近两年向量数据库的热度确实很高笔试中也出现了一道关于向量数据库的简单题什么是向量数据库它和传统关系型数据库在应用场景上有什么区别这道题属于送分题但也不是完全的白给。需要清楚向量数据库的核心能力是向量相似度检索通常基于ANN算法如HNSW、IVF、PQ服务于AIEmbedding检索、RAG、以图搜图等场景。与传统数据库的B树索引不同向量数据库的索引不是用来做精确匹配和范围查询的而是用来做近似最近邻搜索追求的是召回率和查询延迟之间的平衡。另一道关于时序数据库的题目是设计一张时序数据表采集服务器CPU使用率你会怎么设计才能支持高效写入和按时间范围查询这个问题的核心考点包括以时间作为分区键、用设备ID和指标名称作为标签字段、对标签字段建立索引、数据按时间与设备ID的组合排序、考虑数据的保留周期和降采样策略。这类场景如果用MySQL硬扛数据量一大就会遇到写入瓶颈和查询性能问题。而专用时序数据库如Doris、InfluxDB、TDengine在设计上就针对这种数据模型做了优化Doris的聚合模型可以高效处理时序聚合查询TDengine在写入性能和压缩率上有明显优势。准备这类题目不需要成为时序数据库专家但至少应该了解时序数据的基本特征写多读少、按时间排序、高频写入、保留策略以及这些特征如何影响了存储结构的设计。6. 笔试踩坑记录与复盘心得6.1 我实际失分的几类题考完之后我对了一遍答案复盘了自己丢分最严重的地方主要集中在以下几类问题上。第一类是对隔离级别下锁机制的边界条件掌握不精确。比如前面提到的间隙锁问题我只想到了行锁的冲突没有把RR级别下Next-Key Lock的锁定范围计算进去。这导致我对一个场景的判断出现了偏差以为不会阻塞实际上会阻塞。这个问题在面试中很容易被追问建议把《MySQL技术内幕InnoDB存储引擎》里关于锁的章节啃透重点理解记录锁、间隙锁、Next-Key Lock在不同隔离级别下何时加锁、何时释放。我后来自己做实验验证使用两个MySQL会话手动模拟并发事务用SHOW ENGINE INNODB STATUS查看锁等待情况确实比自己啃书直观得多。第二类是SQL窗口函数中GROUP BY的先后顺序。第三道SQL题里先用GROUP BY对同一天多笔订单去重再用窗口函数生成行号。两个操作的顺序如果反了窗口函数计算出的行号就会多出很多最后连续天数的统计全乱掉。这种错误在语法上完全合法不会报错所以特别容易被忽略。建议平时练习时多构造一些边界数据比如同一个用户在同一天下单三次、跨月的连续日期等测试SQL在各种边界情况下的表现。第三类是时间不够用。120分钟看起来充裕但手写SQL要花很多时间在语法思考和自查上设计题又需要写大段的文字说明。我隔壁座位的同学在群里说最后一题只写了三行明显是时间分配出现了问题。我的经验是看到题先快速扫一遍确定哪些题有把握、哪些题需要更多思考先把简单题的分拿稳再集中攻克难题。特别是手写SQL只要逻辑对了阅卷者通常会给予大部分分数不用追求在考场上写出完美无瑕的代码。6.2 给后续批次同学的三条备考建议结合这次笔试的经验我给准备小满后续批次或者其他公司数据库岗笔试的同学三条建议。第一条以MySQL官方文档为主线做系统性复习而不是只看面经。MySQL官方文档中关于InnoDB锁和事务模型的部分写得非常清楚还有示例说明不同隔离级别下的加锁行为。花一个下午读一遍效果远好于翻十篇“MySQL面试题合集”。如果你能把官方文档里锁相关的示例自己动手复现一遍理解深度会完全不一样。第二条刷题时不要只写答案要把解释过程写出来。每次做完一道SQL题在下面写出你的解题思路、时间复杂度和有没有使用索引的考虑。这种输出方式能暴露很多你以为懂了但实际上没有掌握的知识点。同样的对于概念题试着用自己的话把原理讲清楚而不是背原文。第三条关注新趋势但要分清主次。现在确实很多公司会问向量数据库、国产数据库、存算分离这些内容但笔试的主干一定是数据库原理和SQL能力。不要把大量时间花在追新概念上而忽视了事务、索引、锁这些基础中的基础。我的做法是先把基础部分复习扎实再花几个晚上快速了解行业热点形成自己的理解和判断。如果基础不牢新概念知道得再多也很难在笔试中拿分。6.3 笔试与之后面试的衔接笔试结束后大约一周我收到了面试通知。回看整个流程笔试中的不少知识点在面试环节被再次提到比如项目中遇到过死锁吗、怎么定位和解决的如果一张表的数据量到了亿级别你会怎么优化查询有没有了解过公司常用的数据库组件。这说明笔试和面试的考察逻辑是一致的都在验证你是不是真的具备独立解决数据库问题的能力。建议大家笔试结束后不要立刻把题目丢到一边而是趁热打铁把每道题涉及的知识点整理成一份文档特别是那些你做错了的题。这份文档可以成为后续面试准备的复习提纲。我在整理错题时发现很多题目的底层知识点是相通的比如间隙锁的边界条件也和幻读问题的理解相关而幻读问题又与隔离级别的语义相关。把这些知识点串联成一张知识网络比零散地记忆要牢固得多。最后再分享一个小经验笔试的时候对于没有把握的题我倾向于在要点里写出几种可能的情况并加以分析而不是只给一个模棱两可的结论。阅卷者看到你有逻辑地分析问题即便结论不完美也能感受到你的思维过程这比留白好得多。笔试本来就是一种筛选机制它真正想看到的是一个候选人在面对不确定问题时如何拆解、如何推理、如何表达。掌握好这一点不管题目怎么出你都能从容应对。 小满秋招数据库岗笔试复盘：MySQL事务、索引与SQL优化核心考点解析
每年到了七八月份秋招的战线就陆陆续续拉开了。数据库岗作为后端技术栈里非常吃底子的方向笔试题目往往不像前端、客户端那样考一堆框架用法而是扎扎实实考你对数据模型、事务并发、索引原理的理解深度。我参加了2023年度小满秋招数据库岗的第一批笔试整套题做下来最大的感受是它不是在考你背了多少知识点而是在考你有没有真正动手处理过线上问题有没有在夜深人静的时候盯着一个慢查询日志发过呆。这篇文章就围绕这批笔试的完整复盘展开从题型分布到每个模块的核心考点再到我自己踩过的坑一次性梳理清楚。无论是马上要参加后续批次笔试的同学还是准备明年秋招的在校生应该都能从中获得一些可复用的备考思路。1. 这次笔试的总体情况与出题风格1.1 笔试形式与考察范围概览先说整体情况。小满秋招数据库岗的第一批笔试是线上限时作答时长120分钟题量不算特别大但每道题都需要认真思考。整体分为四类题型单选题、多选题、简答题、手写SQL与方案设计题。单选和多选覆盖的是数据库基础理论比如事务隔离级别、索引失效场景、日志机制这些简答题偏向原理阐述比如让你解释MVCC的实现机制、Binlog和Redo Log的区别手写SQL和方案设计题是重头戏占分比例最高考察的是候选人能不能在限定时间内写出正确、高效、可维护的SQL以及面对一个实际业务场景时能不能设计出合理的数据模型。从考察范围来看这批笔试明显偏向MySQL生态同时穿插了不少分布式数据库、国产数据库的内容。这可能和小满自身的技术栈有关。Redis、HBase、Elasticsearch这些周边组件没有直接出大题但在选择题里出现了一些概念性的判断比如Redis持久化机制、HBase的LSM-Tree结构等等。整体来看题目设计得很克制没有偏题怪题每一道都能在常规的学习路径里找到对应出处。1.2 出题思路分析为什么这样设计我个人总结下来这套笔试题的出题风格可以用一句话概括基于真实的数据库运维和开发场景考察候选人的底层原理掌握程度和问题排查能力。举个例子单选题里有一道关于死锁的题它没有直接问“死锁的四个必要条件是什么”而是给了一个具体的并发操作序列让你判断这两个事务在什么隔离级别下会发生死锁以及MySQL检测到死锁后会选择回滚哪一个事务。这种出题方式非常考验对InnoDB锁机制的理解。如果你只是背过“互斥、持有并等待、不可剥夺、循环等待”这四个词遇到这种题基本只能靠猜。同样的简答题里让你对比Binlog和Redo Log如果只是回答“一个是逻辑日志、一个是物理日志”那只能拿到基础分。出题人想看到的是你能不能说清楚为什么MySQL需要两种日志它们各自在什么阶段产生、什么阶段发挥作用以及崩溃恢复时它们是怎么配合的。对于准备笔试的同学来说这种出题风格意味着不能只看面经和八股文需要真正去读一读官方文档甚至亲手搭一套MySQL环境做实验验证。2. SQL基本功从增删改查到复杂查询2.1 手写SQL的考点与陷阱这批笔试的手写SQL题一共有三道分布在试卷的不同部分。第一道是基础的增删改查给了一张订单表和一张用户表要求写出“查询2023年5月下单次数超过3次的用户ID和下单次数按照下单次数降序排列”这样的查询语句。虽然看起来很基础但里面埋了三个小坑时间范围过滤应该怎么写才能利用上索引、分组后过滤用HAVING还是WHERE、以及ORDER BY的排序规则。如果对时间字段的处理不当比如在WHERE里对时间列使用了函数导致索引失效就很容易被后面的附加题问住。我记得这题的第二个小问就是让你说明自己的SQL为什么能走索引这明显是在考隐式类型转换和函数操作对索引的影响。第二道题是INSERT ... ON DUPLICATE KEY UPDATE的运用。场景是每日统计报表要求把当天每个商品类别的销售额写入统计表如果当天已有记录则累加销售额。这道题除了考察写入逻辑还给了一个候选方案让你评价先查一次判断是否存在再决定INSERT还是UPDATE。这种先查后写的方式在高并发场景下存在竞态条件问题而ON DUPLICATE KEY UPDATE是原子性的通过唯一键冲突直接走更新路径。类似的做法还有REPLACE INTO但REPLACE INTO在冲突时会先删除旧记录再插入新记录如果表上有外键或者自增ID可能会引发不期望的行为。这一题很能拉开差距。2.2 窗口函数与复杂查询第三道SQL题难度明显上了一个台阶要求使用窗口函数计算“每个用户在连续下单天数中的最大连续天数”。这道题在LeetCode上能找到原型但在笔试场景下需要在没有IDE提示的情况下手写完成。窗口函数的核心思路是先用LAG或ROW_NUMBER生成每个用户订单日期的排序编号然后通过日期减去编号的差值来判断连续性。如果差值相同说明这些日期是连续的。我在考场上用的是ROW_NUMBER()配合DATE_SUB的方式WITH user_orders AS ( SELECT user_id, order_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date) AS rn FROM orders GROUP BY user_id, order_date ), diff_calc AS ( SELECT user_id, order_date, DATE_SUB(order_date, INTERVAL rn DAY) AS diff FROM user_orders ) SELECT user_id, MAX(consecutive_days) AS max_consecutive_days FROM ( SELECT user_id, COUNT(*) AS consecutive_days FROM diff_calc GROUP BY user_id, diff ) t GROUP BY user_id;这里有一个隐藏的细节同一个用户在同一天可能有多笔订单所以必须先用GROUP BY user_id, order_date去重否则窗口函数的行号会对不上。考场上很容易漏掉这一步导致整个计算结果错误。这类题考察的不只是窗口函数的语法还考察了面对真实业务数据时能不能识别出数据质量问题。2.3 写SQL时的习惯与自查清单笔试和实际工作中写SQL有一个共同的难点很难立刻知道自己的SQL是否正确。在实际工作中可以explain、可以跑测试数据验证但在笔试场景下只能靠逻辑推演。我在这批笔试中总结了一个自查清单分享给大家字段名和表名是否与题目给出的完全一致大小写和反引号是否处理正确多表连接时ON条件是否写清楚了关联字段有没有产生笛卡尔积的风险分组统计时SELECT出的非聚合字段是否都在GROUP BY中在ONLY_FULL_GROUP_BY模式下会直接报错WHERE和HAVING的过滤时机是否搞清楚能不能在WHERE阶段就过滤掉不需要的行时间字段的类型是DATETIME还是TIMESTAMP比较时是否需要考虑时区子查询的关联条件是否写对了相关子查询和非相关子查询在性能上的差异是否考虑过这张清单看起来很简单但在限定时间内能逐项自查的候选人并不多。平时练习的时候最好养成这个习惯形成肌肉记忆。3. 事务、锁与并发控制笔试里的硬骨头3.1 事务隔离级别的场景判断事务隔离级别这部分的考察是整张试卷中选择题密度最高的区域。有一道题给了四个并发执行的事务每个事务都执行了一系列读写操作让你判断在Read Committed和Repeatable Read两种隔离级别下某个SELECT语句分别会读到什么结果。这道题需要非常清晰地理解当前读和快照读的区别以及在不同隔离级别下快照的生成时机。在Read Committed级别下每次SELECT都会生成一个新的快照所以能读到其他事务已经提交的数据而在Repeatable Read级别下快照在第一次SELECT时就固定了后续的SELECT都基于这个快照即使其他事务提交了新数据也看不到。但要注意这里说的是普通SELECT快照读如果SELECT语句带上了FOR UPDATE或者LOCK IN SHARE MODE就变成了当前读读到的一定是最新已提交的数据并且会对记录加锁。这道题就是拿这两种读模式混合出题让考生判断到底读到什么、锁住什么。MVCC机制是回答这类题的基础。InnoDB的MVCC通过隐藏字段DB_TRX_ID最后修改事务ID和DB_ROLL_PTR回滚指针来实现配合undo log构建版本链。ReadView是判断版本可见性的核心里面记录了活跃事务ID列表、最小活跃事务ID、最大事务ID等关键信息。评判一条记录是否可见时规则可以总结为如果版本的事务ID小于最小活跃ID说明已经提交可见如果大于等于最大ID说明是未来事务不可见如果落在中间则需要判断该事务ID是否在活跃列表里如果在则不可见否则可见。这套规则在两种隔离级别下的差异只在于ReadView的生成时机。3.2 死锁场景分析与解决思路关于死锁的题目试卷里有足足三道分布在单选和多选中这种出题密度足以看出小满对这块的重视程度。其中一道选择题的大意是事务A先更新了表t1的id1记录再更新表t2的id2记录事务B先更新表t2的id2记录再更新表t1的id1记录。在RR隔离级别下两个事务同时执行是否会死锁如果需要解决有哪些手段这题典型考察死锁的四个必要条件互斥、持有并等待、不可剥夺、循环等待。两个事务都持有对方需要的锁同时又在等待对方释放形成了闭环所以必然死锁。解决手段可以从多个层面回答调整业务SQL的顺序让所有事务都按照相同的顺序访问表使用事务超时机制innodb_lock_wait_timeout控制等待时间InnoDB本身有死锁检测机制大约每秒检测一次发现死锁后会回滚其中一个事务通常是undo log较少、回滚代价小的事务。这里有一个容易被忽略的细节在RR级别下如果事务A先按条件更新了多条记录比如UPDATE ... WHERE status1插入了一条满足条件的记录但事务A还没有提交那么事务B插入同一条件范围的记录时会遇到间隙锁Gap Lock的阻塞而不是等到真正插入时才冲突。间隙锁锁的是索引记录之间的间隙目的是防止幻读。在RR隔离级别下InnoDB通过Next-Key Lock记录锁间隙锁的组合来解决幻读问题。这道题的陷阱就在于很多人只知道行锁忽略了间隙锁的存在导致判断失误。3.3 连接池参数与线上问题排查还有一道多选题是关于数据库连接池的给了HikariCP的几个参数maximumPoolSize、minimumIdle、connectionTimeout、idleTimeout、maxLifetime让你判断哪些参数设置不当会引发连接耗尽或连接失效问题。这道题虽然理论性不强但非常贴近实际运维场景。连接池参数设置不合理确实是生产环境最常见的故障源之一。maximumPoolSize设置太小高峰期并发一上来连接就不够用了业务侧会报“Connection is not available, request timed out”设置太大数据库端会维护大量空闲连接浪费内存而且MySQL默认的max_connections是151超出后新连接会被拒绝。minimumIdle和idleTimeout配合不当会导致连接池频繁创建和销毁连接。maxLifetime如果设置得比数据库wait_timeout还大可能会出现连接被数据库端断开但连接池不知道的情况应用拿到一个失效连接后执行SQL就会报“Connection has been closed”之类的异常。这些内容在字节、美团的面试经验里经常出现但这批笔试直接用选择题考察说明出题者希望候选人不是只懂理论而是真的关注过线上连接池告警。备考时最好把HikariCP、Druid、C3P0这几个常用连接池的参数都过一遍并理解每个参数设置背后的考量。4. 索引与执行计划从原理到优化实战4.1 索引数据结构选型与底层原理索引部分的知识点在笔试中占了很大比例。单选和多选加起来至少有六道题是关于索引的包括索引数据结构、索引失效场景、覆盖索引、索引下推等内容。其中一道题问的是为什么InnoDB选择B树而不是B树或哈希表作为索引的数据结构这道题的答题要点在于说清楚B树的几个特性。B树的非叶子节点不存储数据只存储索引键值和指向子节点的指针因此单页能承载的键值数量远大于B树树的高度更低磁盘IO次数更少。B树的所有数据都存储在叶子节点上并且叶子节点之间通过双向链表连接这让范围查询和排序操作非常高效——只需要找到范围的起点然后顺着链表向后遍历即可。哈希表虽然等值查询是O(1)的复杂度但无法支持范围查询也无法利用索引进行排序和前缀匹配。B树虽然在每个节点都存储数据但单页能容纳的键值数量少树的高度高而且范围查询需要中序遍历性能远不如B树。题目的加分项是提到InnoDB的主键索引和二级索引在叶子节点上存储的内容是不同的。主键索引的叶子节点存储完整行数据二级索引的叶子节点存储主键值所以通过二级索引查询数据时如果需要回表会先根据二级索引查出主键值再回到主键索引中定位完整记录。如果二级索引已经覆盖了查询所需的全部字段就不需要回表了这就是覆盖索引优化。4.2 索引失效的典型场景关于索引失效有一道多选题列出了五种查询条件让你判断哪些无法使用phone字段上的普通索引WHERE phone LIKE 138%WHERE SUBSTR(phone, 1, 3) 138WHERE phone 0 13812345678WHERE phone 13812345678WHERE phone IN (13812345678, 13912345678)这道题考察的是索引失效的常见原因。对索引列进行了函数操作会导致索引失效这是数据库优化器无法直接利用索引树进行范围定位的原因。对索引列进行隐式类型转换也会导致索引失效因为MySQL需要对字段进行类型转换后再比较。但LIKE 138%这种前缀匹配是可以走索引的这利用了B树的字符串排序特性。IN操作在MySQL优化器中一般会转化为多个等值条件的OR组合是可以走索引的。考场上需要注意的一个细节是隐式类型转换如果phone字段是字符串类型但查询条件是phone 13812345678数字会被转换成字符串再比较。根据MySQL的规则当字符串列和数字比较时字符串会被转换为数字这意味着需要对每一行的phone列值做一次转换索引就失效了。所以正确答案是第二个、第三个和第四个第四个需要看字段类型如果字段是字符串而参数是数字则失效。4.3 执行计划解读与慢查询定位简答题中有一道是给你一段执行计划让你说明这段SQL可能存在的性能问题并给出优化建议。执行计划中展示的关键字段包括type、key、rows、Extra这些。给出的执行计划大致是这样的type是ALL说明是全表扫描没有走到索引rows是100万说明优化器估算需要扫描100万行Extra字段中有Using filesort说明排序操作没有用到索引需要额外的文件排序。我把这道题的答案拆成三步来写第一步优先解决全表扫描问题。看WHERE条件里的字段是否适合建索引如果查询主要是等值过滤建立普通索引就够用了如果是范围查询需要评估索引选择性选择区分度高的字段作为索引的前导列。第二步解决排序问题。如果查询结果集很大并且需要排序考虑建立联合索引让排序字段包含在索引中这样优化器可以直接利用索引的有序性避免filesort。第三步控制返回的数据量。如果业务只需要前20条数据但SQL中缺少LIMIT优化器可能需要把所有满足条件的数据都找出来再排序这会造成不必要的资源消耗。执行计划这道题在笔试和实际工作中都属于高频考点。建议大家提前把explain输出中的每个字段含义好好过一遍特别是type从system到ALL的级别顺序以及Extra中Using index、Using where、Using temporary、Using filesort分别代表什么问题。5. 数据库设计与新趋势考点国产库、向量库与时序库5.1 数据库设计范式与反范式设计题部分给出了一个电商场景用户表、商品表、订单表、订单明细表、商品分类表要求设计订单查询功能的数据模型并给出核心表的字段设计和索引设计。这道题没有标准答案但阅卷者会从几个维度打分有没有合理拆分表结构、字段类型选择是否合理、索引设计是否覆盖了核心查询路径、有没有考虑数据量增长后的扩展方案。我在设计时优先满足的是三范式把订单明细和订单主表分开避免重复存储用户信息。但在商品名称这个字段上我主动做了反范式设计——在订单明细表里冗余了下单时的商品快照信息商品名称、单价、图片URL等。原因是商品信息可能会更新如果不做快照历史订单的展示就会出问题。这种方式在电商系统里非常常见也是面试中考察反范式设计优劣的经典场景。冗余带来的好处是查询订单时不需要回商品表补信息坏处是如果商品信息变化历史订单里的快照不会跟着变。这个取舍需要根据业务需求来判断。索引设计上我为核心查询路径建立了几个索引订单表以user_id create_time作为联合索引支持“我的订单”按时间倒序分页查询订单明细表以order_id建立二级索引因为查询订单明细时总是通过订单ID去关联商品表以category_id建立索引支持分类浏览。这里有一个容易忽略的点订单号本身如果是一个雪花ID或UUID那么它作为主键时在B树上的插入是随机的这会导致页分裂写入性能下降。很多生产系统会用全局ID生成器生成有序ID或者使用自增ID作为主键而订单号作为独立唯一索引。5.2 国产数据库的考察方式这批笔试中有一道关于国产数据库的题目让我印象很深。题目对比了达梦数据库和人大金仓数据库在兼容性方面的差异要求说明它们在对接MySQL或Oracle应用时各有什么优势。这其实反映了近两年国产数据库在金融、政务、电信等行业加速落地的背景秋招出题提到它们并不意外。达梦在很多场景下主打的是对Oracle的兼容包括PL/SQL语法、包、存储过程、触发器这些特性让原有的Oracle应用可以低成本地迁移过来。人大金仓的KingbaseES在兼容Oracle的同时也对PostgreSQL生态有较好的兼容性因为它的内核大量参考了PostgreSQL。题目还问到了如果从Oracle迁移到达梦需要注意哪些点。我的回答从几个方面展开数据类型映射的差异、自增序列的实现方式、存储过程的语法差异、分页查询的写法差异Oracle用ROWNUM达梦支持LIMIT、以及排序空值处理逻辑等。这个知识点看起来有一定门槛但备考时不用过于恐慌。重点还是回到数据库原理的基本面事务、锁、索引、日志。国产数据库和MySQL、Oracle在这些基本原理上是共通的差别主要体现在语法和工具链上。只要原理扎实迁移和适配的问题是可以快速学习的。5.3 向量数据库与时序数据库的考点最近两年向量数据库的热度确实很高笔试中也出现了一道关于向量数据库的简单题什么是向量数据库它和传统关系型数据库在应用场景上有什么区别这道题属于送分题但也不是完全的白给。需要清楚向量数据库的核心能力是向量相似度检索通常基于ANN算法如HNSW、IVF、PQ服务于AIEmbedding检索、RAG、以图搜图等场景。与传统数据库的B树索引不同向量数据库的索引不是用来做精确匹配和范围查询的而是用来做近似最近邻搜索追求的是召回率和查询延迟之间的平衡。另一道关于时序数据库的题目是设计一张时序数据表采集服务器CPU使用率你会怎么设计才能支持高效写入和按时间范围查询这个问题的核心考点包括以时间作为分区键、用设备ID和指标名称作为标签字段、对标签字段建立索引、数据按时间与设备ID的组合排序、考虑数据的保留周期和降采样策略。这类场景如果用MySQL硬扛数据量一大就会遇到写入瓶颈和查询性能问题。而专用时序数据库如Doris、InfluxDB、TDengine在设计上就针对这种数据模型做了优化Doris的聚合模型可以高效处理时序聚合查询TDengine在写入性能和压缩率上有明显优势。准备这类题目不需要成为时序数据库专家但至少应该了解时序数据的基本特征写多读少、按时间排序、高频写入、保留策略以及这些特征如何影响了存储结构的设计。6. 笔试踩坑记录与复盘心得6.1 我实际失分的几类题考完之后我对了一遍答案复盘了自己丢分最严重的地方主要集中在以下几类问题上。第一类是对隔离级别下锁机制的边界条件掌握不精确。比如前面提到的间隙锁问题我只想到了行锁的冲突没有把RR级别下Next-Key Lock的锁定范围计算进去。这导致我对一个场景的判断出现了偏差以为不会阻塞实际上会阻塞。这个问题在面试中很容易被追问建议把《MySQL技术内幕InnoDB存储引擎》里关于锁的章节啃透重点理解记录锁、间隙锁、Next-Key Lock在不同隔离级别下何时加锁、何时释放。我后来自己做实验验证使用两个MySQL会话手动模拟并发事务用SHOW ENGINE INNODB STATUS查看锁等待情况确实比自己啃书直观得多。第二类是SQL窗口函数中GROUP BY的先后顺序。第三道SQL题里先用GROUP BY对同一天多笔订单去重再用窗口函数生成行号。两个操作的顺序如果反了窗口函数计算出的行号就会多出很多最后连续天数的统计全乱掉。这种错误在语法上完全合法不会报错所以特别容易被忽略。建议平时练习时多构造一些边界数据比如同一个用户在同一天下单三次、跨月的连续日期等测试SQL在各种边界情况下的表现。第三类是时间不够用。120分钟看起来充裕但手写SQL要花很多时间在语法思考和自查上设计题又需要写大段的文字说明。我隔壁座位的同学在群里说最后一题只写了三行明显是时间分配出现了问题。我的经验是看到题先快速扫一遍确定哪些题有把握、哪些题需要更多思考先把简单题的分拿稳再集中攻克难题。特别是手写SQL只要逻辑对了阅卷者通常会给予大部分分数不用追求在考场上写出完美无瑕的代码。6.2 给后续批次同学的三条备考建议结合这次笔试的经验我给准备小满后续批次或者其他公司数据库岗笔试的同学三条建议。第一条以MySQL官方文档为主线做系统性复习而不是只看面经。MySQL官方文档中关于InnoDB锁和事务模型的部分写得非常清楚还有示例说明不同隔离级别下的加锁行为。花一个下午读一遍效果远好于翻十篇“MySQL面试题合集”。如果你能把官方文档里锁相关的示例自己动手复现一遍理解深度会完全不一样。第二条刷题时不要只写答案要把解释过程写出来。每次做完一道SQL题在下面写出你的解题思路、时间复杂度和有没有使用索引的考虑。这种输出方式能暴露很多你以为懂了但实际上没有掌握的知识点。同样的对于概念题试着用自己的话把原理讲清楚而不是背原文。第三条关注新趋势但要分清主次。现在确实很多公司会问向量数据库、国产数据库、存算分离这些内容但笔试的主干一定是数据库原理和SQL能力。不要把大量时间花在追新概念上而忽视了事务、索引、锁这些基础中的基础。我的做法是先把基础部分复习扎实再花几个晚上快速了解行业热点形成自己的理解和判断。如果基础不牢新概念知道得再多也很难在笔试中拿分。6.3 笔试与之后面试的衔接笔试结束后大约一周我收到了面试通知。回看整个流程笔试中的不少知识点在面试环节被再次提到比如项目中遇到过死锁吗、怎么定位和解决的如果一张表的数据量到了亿级别你会怎么优化查询有没有了解过公司常用的数据库组件。这说明笔试和面试的考察逻辑是一致的都在验证你是不是真的具备独立解决数据库问题的能力。建议大家笔试结束后不要立刻把题目丢到一边而是趁热打铁把每道题涉及的知识点整理成一份文档特别是那些你做错了的题。这份文档可以成为后续面试准备的复习提纲。我在整理错题时发现很多题目的底层知识点是相通的比如间隙锁的边界条件也和幻读问题的理解相关而幻读问题又与隔离级别的语义相关。把这些知识点串联成一张知识网络比零散地记忆要牢固得多。最后再分享一个小经验笔试的时候对于没有把握的题我倾向于在要点里写出几种可能的情况并加以分析而不是只给一个模棱两可的结论。阅卷者看到你有逻辑地分析问题即便结论不完美也能感受到你的思维过程这比留白好得多。笔试本来就是一种筛选机制它真正想看到的是一个候选人在面对不确定问题时如何拆解、如何推理、如何表达。掌握好这一点不管题目怎么出你都能从容应对。