笔试出来那天下着小雨我在地铁上把手机里的备忘录翻来覆去地划脑子里全是几张没把握的SQL题和一些模棱两可的概念判断。2023年度小满春招数据库岗第三批笔试整体题量不算夸张但出题思路比我想象中更贴近生产环境不是那种背背八股就能过的卷子。它考察的范围覆盖了SQL基本功、事务与锁机制、索引优化、数据库架构设计还有国产数据库和工具链的认知而且很多题都包装成了实际业务场景。这篇文章就是我对这批笔试的完整复盘从题型分布到高频考点再到踩坑教训和备战建议希望能给接下来要参加同类岗位笔试的朋友一些参考。1. 这场笔试的整体画像模块分布与难度档位先说结论这份卷子的难度属于中等偏上但它的偏不在偏题怪题而在每一道题都往深处多问了一层。如果你只是把《数据库系统概论》教材翻熟了大概能拿下基础题但区分度最高的部分恰恰是那些看似见过、实则问法更刁钻的题。从模块分布来看我印象里整份卷子大致分为四块模块题型大致占比核心考察点概念与原理选择题、判断题30%事务隔离级别、索引结构、日志机制、范式、锁的类型SQL书写手写SQL30%多表关联、分组聚合、窗口函数、增删改查的边界场景场景分析与优化简答、设计题30%慢SQL定位、索引优化、死锁排查、主从架构设计生态与工具认知选择、简答10%国产数据库选型、同步工具、数据库客户端、向量数据库等新方向时间上是90分钟题量大概35到40道说实话不算宽裕。我自己的节奏是选择题控制在25分钟内SQL题预留40分钟剩下时间给场景大题最后10分钟检查。这个节奏在后半段还是有点紧尤其是有一道涉及多表关联加窗口函数的SQL题我写完之后反复验算了两次才确信结果没问题。如果说要给这批笔试定个性我的感受是它不考你知道什么而是考你用过之后理解了什么。比如它不会直接问什么是索引最左前缀原则而是给一张联合索引表再给出三个查询条件让你判断哪些能走索引、哪些不能并且要说明理由。这种出题方式对实操经验的要求明显高于对背诵的要求。难度档位上我把它分成三档基础送分题大概占四成比如事务的ACID特性、B树相比B树的优势、普通索引和唯一索引的区别这些属于复习过就能拿分中档题占四成比如MVCC的快照读和当前读区别、间隙锁的作用范围、一个慢SQL的完整优化链路需要你真正理解原理才能答得完整剩下的两成属于拉开差距的题考察的是对数据库生态的广度认知和架构设计思维比如在一个高并发读写场景下如何选择分库分表方案、如何兼顾数据同步的实时性和一致性。这里要多说一句很多人在备战数据库岗笔试时容易陷入一个误区只刷SQL题不碰原理。但我可以负责任地说这份卷子的SQL题只靠刷题能拿到的分很有限真正的重头戏是把原理题答出深度。原理题考察的不光是记忆更是你是否踩过那些坑。比如它问为什么有时候表里明明有索引查询却依然很慢这种问题如果没在真实环境里排查过慢SQL光靠背是答不出那个味儿的。2. SQL考察从增删改查到慢查询诊断考的不是语法而是思维这部分的题目虽然叫SQL书写但它的考察重心绝对不止书写本身。我印象最深的是它给了一个订单表和商品表的业务场景要求统计每个品类销量前3的商品这题一看就是要用窗口函数但它还埋了一个坑同一商品有多条记录、同一订单可能包含多个商品如果先关联再排名结果就会因为笛卡尔积被放大。实际上这类题的正确解法是先按商品聚合销量再在聚合结果上开窗排名。这种看起来是SQL题、其实考的是业务建模和去重思维的题在这份卷子里不止一道。所以我建议准备这类笔试时每做一道SQL题都多问自己一句如果数据里有重复、有NULL、有关联爆炸我的写法还成立吗2.1 聚合查询的边界条件GROUP BY相关的问题几乎是必考的而且它特别喜欢在细节上做文章。这次笔试有一道题是统计每个用户首次下单后的次日留存率很多人第一反应是直接用JOIN两次搞定但更严谨的做法是先用窗口函数ROW_NUMBER()把每个用户最早的下单时间找出来再关联第二天的活跃记录。这两种写法在数据量小的时候结果都一样但在真实的高并发业务库里前者的执行效率会差一个量级。还有一个经典的坑SELECT子句里出现的非聚合列必须出现在GROUP BY里。但在某些数据库的宽松模式比如MySQL的ONLY_FULL_GROUP_BY被关闭时下它不会报错却会返回一个毫无意义的值。笔试里它可能不会直接考这个但它会换一种方式考给你一个查询结果让你判断错误原因。这时候就考验你对SQL标准与实际数据库行为差异的熟悉程度了。2.2 增删改查的高级变体增删改查CRUD这个词看起来基础但笔试里的CRUD很少有直接考单表插入和查询的。它更常见的是让你处理这些场景批量插入时如果主键或唯一索引冲突了是UPDATE还是忽略这就需要区分INSERT INTO ... ON DUPLICATE KEY UPDATE和INSERT IGNORE的语义差异。有一道题是要求把A表的数据同步到B表A表有新增也有更新。很多人写的是先DELETE再INSERT但这样会带来自增ID变化和索引重建的开销。更好的写法是MERGE或等价的分两步操作先更新已存在的记录再插入不存在的记录。关于UPDATE和DELETE的WHERE条件它专门出了一道题问如果一个UPDATE语句的WHERE条件里的子查询跟目标表是同一张表会不会报错这在MySQL里确实会有限制不能一边查询一边更新同一张表解决办法是包一层临时表。这种题如果没有实操经验真的容易掉坑。2.3 窗口函数是必考项窗口函数大概是近几年数据库岗笔试里出镜率最高的知识点。这次卷子涉及到的窗口函数至少有ROW_NUMBER()、RANK()、DENSE_RANK()、SUM() OVER()这几类。它考察的不仅是你会不会写而是你知不知道它们之间的细微差别。比如RANK和DENSE_RANK在遇到并列排名时跳不跳号这决定了业务报表里的名次是否连续。我还遇到一道题问的是累计销售额怎么算。累计值这个场景在日常写SQL里太常见了很多人会想到用自连接去累加但效率很低实际上用SUM(amount) OVER (ORDER BY order_date)一行就能搞定。窗口函数在笔试中的高频出现本质上是考察你是否具备现代SQL的书写意识毕竟在真实业务中窗口函数往往是处理每组取前N条计算移动平均同比环比这类需求的最优解。2.4 慢SQL诊断题从执行计划反推索引缺失这部分是我认为整张卷子里最有实战价值的一类题。它给了你在生产环境里常见的一个场景一张订单表的数据量在千万级某个分页查询越往后翻越慢让你分析原因并给出优化方案。这背后涉及的知识点是传统LIMIT offset, size在大偏移量时需要扫描掉offset之前的行再丢弃成本极高。优化思路一般有几种延迟关联先查出目标页的主键ID再回表关联其他字段。基于游标的分页用上一次查询的最后一个ID作为下一次查询的起点配合WHERE id ? LIMIT 10。覆盖索引如果查询列都包含在索引中就能避免回表。笔试里还有一题给了带EXPLAIN的输出片段让你指出其中的Using filesort、Using temporary、typeALL等关键词分别代表什么问题。这里我要强调一个常见误区很多人知道typeALL是全表扫描但不知道在什么情况下优化器会放弃索引。比如对索引列做了函数运算、隐式类型转换、LIKE以通配符开头、OR连接的非索引列条件、联合索引不满足最左前缀原则这些都会导致索引失效。这一类知识点在笔试里几乎是送分题但也是很多人考完对答案才发现自己错得离谱的地方。3. 事务、锁与死锁笔试里最考验底层理解的连环题如果说SQL题是送分题和拉分题的混合那事务与锁相关的题目就是整张卷子的分水岭。它考察的不再是你会不会写SQL而是你知不知道数据库在底层是怎么保证正确性的。这批笔试在这个模块里出题非常密集从隔离级别到MVCC从行锁到间隙锁从死锁日志到解决方案几乎连成了一条完整的知识链。3.1 隔离级别的边界场景事务隔离级别是必考的基础题但它通常不会直接问四种隔离级别分别是什么而是给你一个具体的并发场景让你判断会出现什么问题。比如会话A开启事务后更新了一行但未提交会话B此时读这行数据在不同隔离级别下分别会读到什么又比如会话A范围查询后会话B插入了一条新记录那么在RR可重复读和RC读已提交隔离级别下会话A再次查询会不会多出这条记录幻读这里有一个很多人容易忽略的点MySQL默认的RR隔离级别理论上应该存在幻读问题但InnoDB通过间隙锁和MVCC的配合在特定条件下规避了幻读。所以要答好这道题光背隔离级别的定义是不够的还得理解它背后的实现机制。笔试里它甚至问到了快照读和当前读的区别普通的SELECT是快照读不加锁读的是快照而SELECT ... FOR UPDATE、UPDATE、DELETE是当前读读的是最新版本并加锁。这个区分直接决定了你在RR级别下会不会触发间隙锁。3.2 MVCC的实现机制MVCC多版本并发控制是InnoDB实现高并发读写的核心机制也是笔试里的高频考点。它涉及到的几个关键概念是隐藏字段DB_TRX_ID、DB_ROLL_PTR、undo log版本链、read view的生成规则。一个典型的题目是在RC和RR两种隔离级别下同一个事务里两次相同的SELECT是否结果一定一致考试里给了一个三行数据的简单表模拟两个事务交叉执行让你判断每次SELECT返回什么结果。这种题本质上是考察你是否理解read view的生成时机。RC级别下每次SELECT都会生成新的read view所以可能会读到其他事务已提交的数据RR级别下只在第一次SELECT时生成read view之后整个事务都用同一份快照。我当时答这类题的方法是先把每个事务的执行序列画出来标出每行数据在不同时刻的DB_TRX_ID然后逐一对应read view的活跃事务列表去判断可见性。这个过程在纸上花不了几分钟但能有效避免凭直觉作答的错误。3.3 锁的分类与加锁规则关于锁的题目主要有两个方向一是锁的类型与兼容性二是加锁的范围。前者包括共享锁、排他锁、意向锁之间的兼容关系以及不同粒度锁的冲突矩阵。后者是更重头的考法给定一条SQL让你判断它会对哪些记录加什么锁。比如在RR隔离级别下SELECT * FROM t WHERE id 100 FOR UPDATE如果id上有主键索引它会对id100的所有记录加行锁同时对它们之间的间隙加间隙锁next-key lock。如果where条件里的列没有索引那问题就更复杂了InnoDB会对全表所有记录加锁因为此时没法精准定位行。有一个容易被忽略的细节是间隙锁只在RR级别下存在RC级别为了支持binlog格式的需要只加行锁以及唯一索引等值查询命中时不会加间隙锁因为不需要防止幻读。这些细节如果没理解透遇到场景判断题极易失分。3.4 死锁的完整排查链路这部分是我在批笔试里非常喜欢的一类题因为它不会直接告诉你这俩事务会死锁而是给你两段并发执行的事务语句和一张MySQL死锁日志的片段让你分析死锁发生的原因和解决办法。这种题非常贴近真实工作因为线上死锁日志就是长那样的。答题时我会按三步走第一步从日志中定位两个事务各自持有的锁和等待的锁第二步画出等待关系图确认是否存在循环等待第三步分析为什么会出现这种情况最后给出解决建议。需要提醒的是这道题的解决建议通常不是杀掉一个事务而是从业务或SQL设计层面优化。常见的思路有调整事务内SQL的执行顺序让所有事务都按同一顺序访问资源减少事务持有锁的时间在RR级别下尽量用RC级别优化索引缩小加锁范围或者对热点行做拆分降低并发冲突。这些建议我在实际工作中都验证过尤其是统一加锁顺序这一条在批量更新场景里几乎能解决八成以上的死锁问题。另外还有一道题提到了数据库并发锁和连接池之间的关系。它问的是当连接池大小设置不当、并发请求增多时为什么会出现线程阻塞和锁等待时间变长。这个问题的本质是连接池的大小决定了并发访问数据库的线程数如果连接数过大数据库端锁竞争加剧如果过小应用端请求排队。它考察的是你是否理解并发控制不只在数据库内部还在应用和数据库之间的连接管理层。4. 索引与执行计划从B树到Explain为什么索引会失效索引模块在这批笔试中的占比不低而且考法非常立体不是简单问索引的作用是什么而是从数据结构选型、索引失效场景、执行计划解读三个层面来考察。这一部分我认为是拿分性价比最高的模块因为知识点相对固定只要梳理清楚短时间内就能提分。4.1 为什么是B树关于索引结构笔试里出现过一个经典问题为什么InnoDB选择B树而不是B树、红黑树或哈希表这道题的答题要点是B树的所有数据都存储在叶子节点并且叶子节点之间通过链表相连这带来两个优势——一是非叶子节点可以存放更多键值树更矮更宽磁盘IO次数更少二是范围查询时可以直接沿叶子节点链表顺序遍历而不需要像B树那样在中序遍历时回溯。哈希索引虽然单点查询很快但不支持范围查询和排序所以只适合特定场景比如等值查询极频繁的缓存表。我在答题时还补充了一点InnoDB的主键索引是聚簇索引叶子节点直接存放整行数据而二级索引的叶子节点存放的是主键值所以通过二级索引查询数据需要回表。这个聚簇索引与二级索引的区别在笔试里对应的一道题是为什么主键不宜过长因为主键越长二级索引就会越大占用的存储空间和IO成本都会上升。4.2 索引失效场景六个高频考点索引失效是笔试中的常客今年这批也不例外。它给了一道复合索引(a, b, c)相关的题目判断四条查询是否命中索引。这背后是最左前缀原则但真正容易失分的是它结合了范围查询的右边索引列会失效这个规则。比如WHERE a 1 AND b 10 AND c 5这个语句因为b使用了范围查询c列就无法继续用到索引了。除了这个还有几个高频失效场景需要熟记对索引列使用函数或表达式比如WHERE DATE(create_time) 2023-01-01这种情况应该改成范围查询条件。隐式类型转换比如varchar列用数字去匹配导致索引失效。LIKE以%开头。使用OR连接条件时如果其中有一个列没有索引整个查询都可能走全表扫描。索引列允许为NULL时某些查询条件下优化器也可能放弃索引虽然这个没有前几个绝对但值得注意。我当时做完这组题后最大的感受是光记住这些场景没用还得理解优化器做成本估算的逻辑。比如在数据量非常小的表里即便存在可用索引优化器也可能选择全表扫描因为它估算全表扫描更快。这一点在笔试里不会直接考但在执行计划题中如果出现typeALL和possible_keys非空的组合很多人就会卡住。4.3 执行计划解读EXPLAIN里的关键字段Explain是分析SQL性能的核心工具笔试里有一道题直接给出了一条慢查询的EXPLAIN结果要求指出问题所在并给出优化方案。我在实际工作中看执行计划一般按这个顺序处理type至少要达到range级别最好能达到ref或const如果是ALL说明全表扫描这是第一个要优化的大红旗。key实际用到的索引是什么有没有可能用了但不是最优的。rows预估扫描行数如果这个数字跟实际返回的行数差距巨大说明统计信息可能过期或用错了索引。Extra有没有Using filesort、Using temporary、Using index condition索引下推、Using index覆盖索引。关于Using filesort它在笔试里的变形是ORDER BY字段顺序和联合索引顺序不一致时如何优化。通常的解决思路是调整索引列顺序让排序字段也满足最左前缀或者把排序和过滤结合起来创建联合索引。但如果你的查询里有范围条件排序字段又在范围条件之后那么排序依然会走filesort。这些细节看起来琐碎却是执行计划题答题是否完整的关键。4.4 覆盖索引与索引下推覆盖索引Using index和索引下推Using index condition是加分项但也是很多人答不全的知识点。覆盖索引指的是SELECT的列都在索引中无需回表这在查询列较少时能显著提升性能。索引下推则是MySQL 5.6以后引入的优化把WHERE条件中可以用索引列判断的部分下推到存储引擎层减少回表次数。有一道题我记得很清楚表t的联合索引是(a, b)查询条件是WHERE a 1 AND b LIKE x%SELECT出的列包含c。这道题的答案是a和b都能利用索引做定位和过滤但由于需要查c列还是需要回表同时b的LIKE条件可以在索引层通过索引下推完成过滤减少回表次数。这种题是一层层递进的答的时候最好把整个执行链路讲清楚而不是直接给结论。5. 从单机到架构主从复制、读写分离与分库分表的设计思维这批笔试的另一个出题方向是数据库架构设计。它没有问纯粹的八股概念而是把问题安插在业务场景中让你在数据量变大、并发变高的前提下给出方案。这类题目没有唯一标准答案但答题的框架和取舍思路是最重要的。5.1 主从复制与读写分离的取舍一道典型的题是一个读多写少的系统数据库压力大你打算引入一主两从的架构做读写分离请问需要考虑哪些问题这题考察的底层原理是binlog的复制机制。MySQL主从复制涉及binlog格式STATEMENT、ROW、MIXED的选择从库通过IO线程拉取主库binlog再由SQL线程重放。这里面最容易出现的问题是从库延迟。如果你在从库上读到的是几秒之前的数据那么某些对数据一致性要求高的读请求比如用户刚下单后马上查订单就不能走从库否则会出现读不到自己写的数据的尴尬。答题时我给出了三层优化思路。第一层从SQL层面减少主库压力重要的读走主库可容忍延迟的读走从库第二层从架构层面引入中间件如ProxySQL做读写分离的路由第三层如果有强一致需求考虑使用MySQL的半同步复制保证主库在事务提交时至少有一个从库收到了binlog。5.2 分库分表的时机与策略另一道题是典型的千万级数据、单表查询变慢的场景问是否应该分库分表以及如何分。这题的关键是先判断是否到了必须分库分表的程度。通常单表数据量在两千万以下、索引合理时MySQL依然能保持较好的性能所以优先考虑的应该是索引优化、归档冷数据、引入缓存。只有QPS和数据量都到了一定规模才需要分库分表。如果真要分分表字段的选择直接决定方案的成败。它给了一个电商系统用户订单表按用户ID分表就是常见做法因为用户的查询都是以用户为中心但运营侧的跨用户查询就没法走分表键需要引入汇总表或搜索引擎。分库分表还会带来分布式ID、跨分片事务、数据迁移等问题回答时如果能提到用美团Leaf或雪花算法生成分布式ID以及用ShardingSphere这类中间件做透明路由会显得更有实战经验。5.3 数据库同步工具与异构数据迁移架构题里还涉及了数据同步的内容。比如主库和从库之间的同步、业务数据同步到数仓、或者MySQL同步到时序数据库/TiDB等场景考察你对数据同步工具的了解程度。这里能说清楚全量同步和增量同步的区别以及增量同步中如何通过binlog订阅比如Canal来捕获数据变更会是很加分的回答。还有一道选择题涉及数据库同步软件的功能边界选项里出现了几个工具考察的是你知不知道它们分别解决什么问题。有些是做实时增量同步的有些是做ETL批处理的有些是做跨机房双向同步的。这类题不算难但如果你平时只用过Navicat或DataGrip做客户端管理没有接触过同步工具可能就会丢分。5.4 SQLite与轻量级数据库的笔试身影令人意外的是笔试里还出现了一道关于SQLite的题考点是它的适用场景和限制。SQLite是典型的单文件数据库在移动端、嵌入式场景和本地工具里应用广泛但不适合高并发写入。这题难度不大但它提醒我数据库岗的考察面并不局限于MySQL和Oracle而是覆盖了整个数据库生态。跟SQLite类似的还有linux下的单文件数据库相关热词这类轻量级数据库在IoT和边缘计算场景中常用。复习时对这些方向有个基本认知就足够应付笔试不需要深挖。6. 技术栈广度从Oracle到国产数据库生态题比想象中更实如果你觉得数据库岗笔试只考MySQL那就低估了出题人的布局。这批笔试的最后一类题目聚焦的是整个数据库生态包括传统商业数据库、国产数据库、数据库工具链以及新兴的向量数据库和时序数据库方向。这部分内容占比不高但很能拉开分差因为它的积累更多来自日常接触和行业关注度。6.1 Oracle与MySQL的习惯差异有一道题涉及Oracle和MySQL在SQL方言上的差异。比如Oracle里字符串拼接用||MySQL用CONCAT函数Oracle的分页用ROWNUM或FETCH FIRSTMySQL用LIMITOracle的序列是显式的SEQUENCEMySQL的自增列是AUTO_INCREMENT。如果只在MySQL环境下学习遇到这类题会有点懵。笔试里还有一个关于Oracle数据库安装和配置的场景题其实考察的不是安装步骤本身而是你对Oracle体系结构的理解比如实例Instance和数据库Database的区别SGA和PGA的作用redo log和undo表空间的设计。如果你在真实的项目里接触过Oracle这些概念会非常熟悉。6.2 国产数据库的崛起与选型逻辑国产数据库是近年笔试热点这批也不例外。它问的是在一个政企类项目中如果有自主可控的要求你会选择哪款国产数据库替代MySQL为什么这道题我完整写了达梦数据库和人大金仓两个方向。达梦数据库在架构上对标Oracle兼容性好适合从Oracle迁移的老系统人大金仓KingbaseES则对PostgreSQL和Oracle的兼容性都不错在信创项目中落地案例较多。同时我还提到了GaussDB在华为生态里的优势以及OceanBase、TiDB这类分布式数据库在高并发场景下的选型思路。答题的核心逻辑不在于你背下了多少产品名而在于你是否有选型方法论。我给出的框架是先看兼容性从存量系统迁移的难易程度再看架构集中式还是分布式然后看生态和社区活跃度最后结合团队的技术栈熟悉度做决策。框架比结论重要得多这也是面试官更希望看到的思维模式。6.3 数据库工具链从dbx到Navicat笔试题里有一道选择题涉及数据库客户端工具的功能对比。它是通过dbx数据库工具这一类热词引申出来的考察你知不知道这些工具各有什么特点。dbx作为一个数据库管理工具核心功能集中在连接管理、SQL编辑、数据导入导出等方面Navicat和DataGrip则是更常见的全平台客户端DBeaver在开源场景里使用率很高而命令行侧的mysql-client和psql虽然不如图形界面友好但在自动化脚本和服务器上没有图形界面的环境里依然是首选。这类题本身不难但它背后反映出的信号是招聘方希望候选人不只是会用Navicat还要具备在多样化工具链下工作的能力。对于笔试我建议你在简历里写到的工具都亲手操作一遍至少知道它支持哪些数据库类型、大致的界面布局和核心功能入口这样遇到工具类选择题根本不用猜。6.4 向量数据库与时序数据库新方向进入考纲向量数据库相关的题目出现在这次笔试里让我有些意外但仔细一想又在情理之中。随着大模型和RAG应用的火热向量数据库的岗位需求在暴涨笔试中自然就多了向量检索、相似度计算、Embedding存储这类概念题。哪怕你目前的工作根本不涉及向量数据库我也建议你对它的核心思想向量索引、近似最近邻搜索、与关系型数据的结合方式有个基本认知。时序数据库也一样它考察的是时序数据库的数据库结构怎样设计。热词里反复出现这个问题说明时序数据的场景监控指标、IoT传感器、金融行情在业务中越来越普遍。时序数据库的核心设计思路是按时间维度分区、数据压缩率高、支持海量高并发写入、聚合查询能力强。如果你能答出这些特点和它与传统关系型数据库的差异在生态题上会非常加分。7. 备战建议拿到一批笔试后的针对性复习路径最后这部分不是总结是我自己从这次笔试里提炼出来的一套复习方法算是给准备春招的朋友一个参考方向。如果你手头已经拿到类似批次的笔试通知可以从以下几个方面做重点投入性价比会非常高。第一SQL必须练到条件反射级别。笔试里的SQL题不会给你太多思考时间尤其是窗口函数和多表关联的组合题考场上临时推演会很紧张。建议把力扣的数据库题库中等难度以上的题都刷一遍重点练窗口函数、连续性问题、分组TopN、留存率计算这几类这些都是笔试里的常客。第二锁和MVCC必须能用语言讲出来。死记硬背最大的问题是遇到场景题你会发现知识点对不上号。我自己的方法是把事务并发问题当成一个角色扮演游戏每次读一条SQL就模拟一下InnoDB底层会加什么锁、读哪个版本、在什么条件下会不会阻塞。这个习惯坚持两三个星期应对笔试里的锁机制题就会轻松很多。第三执行计划必须亲手看过。如果你没有现成的慢SQL可以找一个线上或本地环境用EXPLAIN分析几条不同写法的查询看看type、rows、Extra这些字段如何变化。看得多了笔试里给出一条SQL的执行计划你就能一眼看出问题所在。第四对生态类题目的准备不要过度焦虑。像向量数据库、国产数据库这类内容做到知道是什么、能说出选型思路的程度就够用了不需要花大量时间深入研究。真正的复习重心还是要放在SQL和原理题上这两块能保住80%的分数。最后再分享一个我在考场上用的小技巧遇到拿不准的场景判断题先把题目里的隔离级别和索引情况圈出来再作答。很多看似复杂的并发题只要确定这两个前提答案方向基本就不会跑偏。考试也好做项目也罢数据库岗拼到底的还是对底层机制的清晰认知和对实际场景的准确判断。希望这份复盘对你有用。 2023春招数据库岗笔试复盘：SQL、索引与锁的核心考点
笔试出来那天下着小雨我在地铁上把手机里的备忘录翻来覆去地划脑子里全是几张没把握的SQL题和一些模棱两可的概念判断。2023年度小满春招数据库岗第三批笔试整体题量不算夸张但出题思路比我想象中更贴近生产环境不是那种背背八股就能过的卷子。它考察的范围覆盖了SQL基本功、事务与锁机制、索引优化、数据库架构设计还有国产数据库和工具链的认知而且很多题都包装成了实际业务场景。这篇文章就是我对这批笔试的完整复盘从题型分布到高频考点再到踩坑教训和备战建议希望能给接下来要参加同类岗位笔试的朋友一些参考。1. 这场笔试的整体画像模块分布与难度档位先说结论这份卷子的难度属于中等偏上但它的偏不在偏题怪题而在每一道题都往深处多问了一层。如果你只是把《数据库系统概论》教材翻熟了大概能拿下基础题但区分度最高的部分恰恰是那些看似见过、实则问法更刁钻的题。从模块分布来看我印象里整份卷子大致分为四块模块题型大致占比核心考察点概念与原理选择题、判断题30%事务隔离级别、索引结构、日志机制、范式、锁的类型SQL书写手写SQL30%多表关联、分组聚合、窗口函数、增删改查的边界场景场景分析与优化简答、设计题30%慢SQL定位、索引优化、死锁排查、主从架构设计生态与工具认知选择、简答10%国产数据库选型、同步工具、数据库客户端、向量数据库等新方向时间上是90分钟题量大概35到40道说实话不算宽裕。我自己的节奏是选择题控制在25分钟内SQL题预留40分钟剩下时间给场景大题最后10分钟检查。这个节奏在后半段还是有点紧尤其是有一道涉及多表关联加窗口函数的SQL题我写完之后反复验算了两次才确信结果没问题。如果说要给这批笔试定个性我的感受是它不考你知道什么而是考你用过之后理解了什么。比如它不会直接问什么是索引最左前缀原则而是给一张联合索引表再给出三个查询条件让你判断哪些能走索引、哪些不能并且要说明理由。这种出题方式对实操经验的要求明显高于对背诵的要求。难度档位上我把它分成三档基础送分题大概占四成比如事务的ACID特性、B树相比B树的优势、普通索引和唯一索引的区别这些属于复习过就能拿分中档题占四成比如MVCC的快照读和当前读区别、间隙锁的作用范围、一个慢SQL的完整优化链路需要你真正理解原理才能答得完整剩下的两成属于拉开差距的题考察的是对数据库生态的广度认知和架构设计思维比如在一个高并发读写场景下如何选择分库分表方案、如何兼顾数据同步的实时性和一致性。这里要多说一句很多人在备战数据库岗笔试时容易陷入一个误区只刷SQL题不碰原理。但我可以负责任地说这份卷子的SQL题只靠刷题能拿到的分很有限真正的重头戏是把原理题答出深度。原理题考察的不光是记忆更是你是否踩过那些坑。比如它问为什么有时候表里明明有索引查询却依然很慢这种问题如果没在真实环境里排查过慢SQL光靠背是答不出那个味儿的。2. SQL考察从增删改查到慢查询诊断考的不是语法而是思维这部分的题目虽然叫SQL书写但它的考察重心绝对不止书写本身。我印象最深的是它给了一个订单表和商品表的业务场景要求统计每个品类销量前3的商品这题一看就是要用窗口函数但它还埋了一个坑同一商品有多条记录、同一订单可能包含多个商品如果先关联再排名结果就会因为笛卡尔积被放大。实际上这类题的正确解法是先按商品聚合销量再在聚合结果上开窗排名。这种看起来是SQL题、其实考的是业务建模和去重思维的题在这份卷子里不止一道。所以我建议准备这类笔试时每做一道SQL题都多问自己一句如果数据里有重复、有NULL、有关联爆炸我的写法还成立吗2.1 聚合查询的边界条件GROUP BY相关的问题几乎是必考的而且它特别喜欢在细节上做文章。这次笔试有一道题是统计每个用户首次下单后的次日留存率很多人第一反应是直接用JOIN两次搞定但更严谨的做法是先用窗口函数ROW_NUMBER()把每个用户最早的下单时间找出来再关联第二天的活跃记录。这两种写法在数据量小的时候结果都一样但在真实的高并发业务库里前者的执行效率会差一个量级。还有一个经典的坑SELECT子句里出现的非聚合列必须出现在GROUP BY里。但在某些数据库的宽松模式比如MySQL的ONLY_FULL_GROUP_BY被关闭时下它不会报错却会返回一个毫无意义的值。笔试里它可能不会直接考这个但它会换一种方式考给你一个查询结果让你判断错误原因。这时候就考验你对SQL标准与实际数据库行为差异的熟悉程度了。2.2 增删改查的高级变体增删改查CRUD这个词看起来基础但笔试里的CRUD很少有直接考单表插入和查询的。它更常见的是让你处理这些场景批量插入时如果主键或唯一索引冲突了是UPDATE还是忽略这就需要区分INSERT INTO ... ON DUPLICATE KEY UPDATE和INSERT IGNORE的语义差异。有一道题是要求把A表的数据同步到B表A表有新增也有更新。很多人写的是先DELETE再INSERT但这样会带来自增ID变化和索引重建的开销。更好的写法是MERGE或等价的分两步操作先更新已存在的记录再插入不存在的记录。关于UPDATE和DELETE的WHERE条件它专门出了一道题问如果一个UPDATE语句的WHERE条件里的子查询跟目标表是同一张表会不会报错这在MySQL里确实会有限制不能一边查询一边更新同一张表解决办法是包一层临时表。这种题如果没有实操经验真的容易掉坑。2.3 窗口函数是必考项窗口函数大概是近几年数据库岗笔试里出镜率最高的知识点。这次卷子涉及到的窗口函数至少有ROW_NUMBER()、RANK()、DENSE_RANK()、SUM() OVER()这几类。它考察的不仅是你会不会写而是你知不知道它们之间的细微差别。比如RANK和DENSE_RANK在遇到并列排名时跳不跳号这决定了业务报表里的名次是否连续。我还遇到一道题问的是累计销售额怎么算。累计值这个场景在日常写SQL里太常见了很多人会想到用自连接去累加但效率很低实际上用SUM(amount) OVER (ORDER BY order_date)一行就能搞定。窗口函数在笔试中的高频出现本质上是考察你是否具备现代SQL的书写意识毕竟在真实业务中窗口函数往往是处理每组取前N条计算移动平均同比环比这类需求的最优解。2.4 慢SQL诊断题从执行计划反推索引缺失这部分是我认为整张卷子里最有实战价值的一类题。它给了你在生产环境里常见的一个场景一张订单表的数据量在千万级某个分页查询越往后翻越慢让你分析原因并给出优化方案。这背后涉及的知识点是传统LIMIT offset, size在大偏移量时需要扫描掉offset之前的行再丢弃成本极高。优化思路一般有几种延迟关联先查出目标页的主键ID再回表关联其他字段。基于游标的分页用上一次查询的最后一个ID作为下一次查询的起点配合WHERE id ? LIMIT 10。覆盖索引如果查询列都包含在索引中就能避免回表。笔试里还有一题给了带EXPLAIN的输出片段让你指出其中的Using filesort、Using temporary、typeALL等关键词分别代表什么问题。这里我要强调一个常见误区很多人知道typeALL是全表扫描但不知道在什么情况下优化器会放弃索引。比如对索引列做了函数运算、隐式类型转换、LIKE以通配符开头、OR连接的非索引列条件、联合索引不满足最左前缀原则这些都会导致索引失效。这一类知识点在笔试里几乎是送分题但也是很多人考完对答案才发现自己错得离谱的地方。3. 事务、锁与死锁笔试里最考验底层理解的连环题如果说SQL题是送分题和拉分题的混合那事务与锁相关的题目就是整张卷子的分水岭。它考察的不再是你会不会写SQL而是你知不知道数据库在底层是怎么保证正确性的。这批笔试在这个模块里出题非常密集从隔离级别到MVCC从行锁到间隙锁从死锁日志到解决方案几乎连成了一条完整的知识链。3.1 隔离级别的边界场景事务隔离级别是必考的基础题但它通常不会直接问四种隔离级别分别是什么而是给你一个具体的并发场景让你判断会出现什么问题。比如会话A开启事务后更新了一行但未提交会话B此时读这行数据在不同隔离级别下分别会读到什么又比如会话A范围查询后会话B插入了一条新记录那么在RR可重复读和RC读已提交隔离级别下会话A再次查询会不会多出这条记录幻读这里有一个很多人容易忽略的点MySQL默认的RR隔离级别理论上应该存在幻读问题但InnoDB通过间隙锁和MVCC的配合在特定条件下规避了幻读。所以要答好这道题光背隔离级别的定义是不够的还得理解它背后的实现机制。笔试里它甚至问到了快照读和当前读的区别普通的SELECT是快照读不加锁读的是快照而SELECT ... FOR UPDATE、UPDATE、DELETE是当前读读的是最新版本并加锁。这个区分直接决定了你在RR级别下会不会触发间隙锁。3.2 MVCC的实现机制MVCC多版本并发控制是InnoDB实现高并发读写的核心机制也是笔试里的高频考点。它涉及到的几个关键概念是隐藏字段DB_TRX_ID、DB_ROLL_PTR、undo log版本链、read view的生成规则。一个典型的题目是在RC和RR两种隔离级别下同一个事务里两次相同的SELECT是否结果一定一致考试里给了一个三行数据的简单表模拟两个事务交叉执行让你判断每次SELECT返回什么结果。这种题本质上是考察你是否理解read view的生成时机。RC级别下每次SELECT都会生成新的read view所以可能会读到其他事务已提交的数据RR级别下只在第一次SELECT时生成read view之后整个事务都用同一份快照。我当时答这类题的方法是先把每个事务的执行序列画出来标出每行数据在不同时刻的DB_TRX_ID然后逐一对应read view的活跃事务列表去判断可见性。这个过程在纸上花不了几分钟但能有效避免凭直觉作答的错误。3.3 锁的分类与加锁规则关于锁的题目主要有两个方向一是锁的类型与兼容性二是加锁的范围。前者包括共享锁、排他锁、意向锁之间的兼容关系以及不同粒度锁的冲突矩阵。后者是更重头的考法给定一条SQL让你判断它会对哪些记录加什么锁。比如在RR隔离级别下SELECT * FROM t WHERE id 100 FOR UPDATE如果id上有主键索引它会对id100的所有记录加行锁同时对它们之间的间隙加间隙锁next-key lock。如果where条件里的列没有索引那问题就更复杂了InnoDB会对全表所有记录加锁因为此时没法精准定位行。有一个容易被忽略的细节是间隙锁只在RR级别下存在RC级别为了支持binlog格式的需要只加行锁以及唯一索引等值查询命中时不会加间隙锁因为不需要防止幻读。这些细节如果没理解透遇到场景判断题极易失分。3.4 死锁的完整排查链路这部分是我在批笔试里非常喜欢的一类题因为它不会直接告诉你这俩事务会死锁而是给你两段并发执行的事务语句和一张MySQL死锁日志的片段让你分析死锁发生的原因和解决办法。这种题非常贴近真实工作因为线上死锁日志就是长那样的。答题时我会按三步走第一步从日志中定位两个事务各自持有的锁和等待的锁第二步画出等待关系图确认是否存在循环等待第三步分析为什么会出现这种情况最后给出解决建议。需要提醒的是这道题的解决建议通常不是杀掉一个事务而是从业务或SQL设计层面优化。常见的思路有调整事务内SQL的执行顺序让所有事务都按同一顺序访问资源减少事务持有锁的时间在RR级别下尽量用RC级别优化索引缩小加锁范围或者对热点行做拆分降低并发冲突。这些建议我在实际工作中都验证过尤其是统一加锁顺序这一条在批量更新场景里几乎能解决八成以上的死锁问题。另外还有一道题提到了数据库并发锁和连接池之间的关系。它问的是当连接池大小设置不当、并发请求增多时为什么会出现线程阻塞和锁等待时间变长。这个问题的本质是连接池的大小决定了并发访问数据库的线程数如果连接数过大数据库端锁竞争加剧如果过小应用端请求排队。它考察的是你是否理解并发控制不只在数据库内部还在应用和数据库之间的连接管理层。4. 索引与执行计划从B树到Explain为什么索引会失效索引模块在这批笔试中的占比不低而且考法非常立体不是简单问索引的作用是什么而是从数据结构选型、索引失效场景、执行计划解读三个层面来考察。这一部分我认为是拿分性价比最高的模块因为知识点相对固定只要梳理清楚短时间内就能提分。4.1 为什么是B树关于索引结构笔试里出现过一个经典问题为什么InnoDB选择B树而不是B树、红黑树或哈希表这道题的答题要点是B树的所有数据都存储在叶子节点并且叶子节点之间通过链表相连这带来两个优势——一是非叶子节点可以存放更多键值树更矮更宽磁盘IO次数更少二是范围查询时可以直接沿叶子节点链表顺序遍历而不需要像B树那样在中序遍历时回溯。哈希索引虽然单点查询很快但不支持范围查询和排序所以只适合特定场景比如等值查询极频繁的缓存表。我在答题时还补充了一点InnoDB的主键索引是聚簇索引叶子节点直接存放整行数据而二级索引的叶子节点存放的是主键值所以通过二级索引查询数据需要回表。这个聚簇索引与二级索引的区别在笔试里对应的一道题是为什么主键不宜过长因为主键越长二级索引就会越大占用的存储空间和IO成本都会上升。4.2 索引失效场景六个高频考点索引失效是笔试中的常客今年这批也不例外。它给了一道复合索引(a, b, c)相关的题目判断四条查询是否命中索引。这背后是最左前缀原则但真正容易失分的是它结合了范围查询的右边索引列会失效这个规则。比如WHERE a 1 AND b 10 AND c 5这个语句因为b使用了范围查询c列就无法继续用到索引了。除了这个还有几个高频失效场景需要熟记对索引列使用函数或表达式比如WHERE DATE(create_time) 2023-01-01这种情况应该改成范围查询条件。隐式类型转换比如varchar列用数字去匹配导致索引失效。LIKE以%开头。使用OR连接条件时如果其中有一个列没有索引整个查询都可能走全表扫描。索引列允许为NULL时某些查询条件下优化器也可能放弃索引虽然这个没有前几个绝对但值得注意。我当时做完这组题后最大的感受是光记住这些场景没用还得理解优化器做成本估算的逻辑。比如在数据量非常小的表里即便存在可用索引优化器也可能选择全表扫描因为它估算全表扫描更快。这一点在笔试里不会直接考但在执行计划题中如果出现typeALL和possible_keys非空的组合很多人就会卡住。4.3 执行计划解读EXPLAIN里的关键字段Explain是分析SQL性能的核心工具笔试里有一道题直接给出了一条慢查询的EXPLAIN结果要求指出问题所在并给出优化方案。我在实际工作中看执行计划一般按这个顺序处理type至少要达到range级别最好能达到ref或const如果是ALL说明全表扫描这是第一个要优化的大红旗。key实际用到的索引是什么有没有可能用了但不是最优的。rows预估扫描行数如果这个数字跟实际返回的行数差距巨大说明统计信息可能过期或用错了索引。Extra有没有Using filesort、Using temporary、Using index condition索引下推、Using index覆盖索引。关于Using filesort它在笔试里的变形是ORDER BY字段顺序和联合索引顺序不一致时如何优化。通常的解决思路是调整索引列顺序让排序字段也满足最左前缀或者把排序和过滤结合起来创建联合索引。但如果你的查询里有范围条件排序字段又在范围条件之后那么排序依然会走filesort。这些细节看起来琐碎却是执行计划题答题是否完整的关键。4.4 覆盖索引与索引下推覆盖索引Using index和索引下推Using index condition是加分项但也是很多人答不全的知识点。覆盖索引指的是SELECT的列都在索引中无需回表这在查询列较少时能显著提升性能。索引下推则是MySQL 5.6以后引入的优化把WHERE条件中可以用索引列判断的部分下推到存储引擎层减少回表次数。有一道题我记得很清楚表t的联合索引是(a, b)查询条件是WHERE a 1 AND b LIKE x%SELECT出的列包含c。这道题的答案是a和b都能利用索引做定位和过滤但由于需要查c列还是需要回表同时b的LIKE条件可以在索引层通过索引下推完成过滤减少回表次数。这种题是一层层递进的答的时候最好把整个执行链路讲清楚而不是直接给结论。5. 从单机到架构主从复制、读写分离与分库分表的设计思维这批笔试的另一个出题方向是数据库架构设计。它没有问纯粹的八股概念而是把问题安插在业务场景中让你在数据量变大、并发变高的前提下给出方案。这类题目没有唯一标准答案但答题的框架和取舍思路是最重要的。5.1 主从复制与读写分离的取舍一道典型的题是一个读多写少的系统数据库压力大你打算引入一主两从的架构做读写分离请问需要考虑哪些问题这题考察的底层原理是binlog的复制机制。MySQL主从复制涉及binlog格式STATEMENT、ROW、MIXED的选择从库通过IO线程拉取主库binlog再由SQL线程重放。这里面最容易出现的问题是从库延迟。如果你在从库上读到的是几秒之前的数据那么某些对数据一致性要求高的读请求比如用户刚下单后马上查订单就不能走从库否则会出现读不到自己写的数据的尴尬。答题时我给出了三层优化思路。第一层从SQL层面减少主库压力重要的读走主库可容忍延迟的读走从库第二层从架构层面引入中间件如ProxySQL做读写分离的路由第三层如果有强一致需求考虑使用MySQL的半同步复制保证主库在事务提交时至少有一个从库收到了binlog。5.2 分库分表的时机与策略另一道题是典型的千万级数据、单表查询变慢的场景问是否应该分库分表以及如何分。这题的关键是先判断是否到了必须分库分表的程度。通常单表数据量在两千万以下、索引合理时MySQL依然能保持较好的性能所以优先考虑的应该是索引优化、归档冷数据、引入缓存。只有QPS和数据量都到了一定规模才需要分库分表。如果真要分分表字段的选择直接决定方案的成败。它给了一个电商系统用户订单表按用户ID分表就是常见做法因为用户的查询都是以用户为中心但运营侧的跨用户查询就没法走分表键需要引入汇总表或搜索引擎。分库分表还会带来分布式ID、跨分片事务、数据迁移等问题回答时如果能提到用美团Leaf或雪花算法生成分布式ID以及用ShardingSphere这类中间件做透明路由会显得更有实战经验。5.3 数据库同步工具与异构数据迁移架构题里还涉及了数据同步的内容。比如主库和从库之间的同步、业务数据同步到数仓、或者MySQL同步到时序数据库/TiDB等场景考察你对数据同步工具的了解程度。这里能说清楚全量同步和增量同步的区别以及增量同步中如何通过binlog订阅比如Canal来捕获数据变更会是很加分的回答。还有一道选择题涉及数据库同步软件的功能边界选项里出现了几个工具考察的是你知不知道它们分别解决什么问题。有些是做实时增量同步的有些是做ETL批处理的有些是做跨机房双向同步的。这类题不算难但如果你平时只用过Navicat或DataGrip做客户端管理没有接触过同步工具可能就会丢分。5.4 SQLite与轻量级数据库的笔试身影令人意外的是笔试里还出现了一道关于SQLite的题考点是它的适用场景和限制。SQLite是典型的单文件数据库在移动端、嵌入式场景和本地工具里应用广泛但不适合高并发写入。这题难度不大但它提醒我数据库岗的考察面并不局限于MySQL和Oracle而是覆盖了整个数据库生态。跟SQLite类似的还有linux下的单文件数据库相关热词这类轻量级数据库在IoT和边缘计算场景中常用。复习时对这些方向有个基本认知就足够应付笔试不需要深挖。6. 技术栈广度从Oracle到国产数据库生态题比想象中更实如果你觉得数据库岗笔试只考MySQL那就低估了出题人的布局。这批笔试的最后一类题目聚焦的是整个数据库生态包括传统商业数据库、国产数据库、数据库工具链以及新兴的向量数据库和时序数据库方向。这部分内容占比不高但很能拉开分差因为它的积累更多来自日常接触和行业关注度。6.1 Oracle与MySQL的习惯差异有一道题涉及Oracle和MySQL在SQL方言上的差异。比如Oracle里字符串拼接用||MySQL用CONCAT函数Oracle的分页用ROWNUM或FETCH FIRSTMySQL用LIMITOracle的序列是显式的SEQUENCEMySQL的自增列是AUTO_INCREMENT。如果只在MySQL环境下学习遇到这类题会有点懵。笔试里还有一个关于Oracle数据库安装和配置的场景题其实考察的不是安装步骤本身而是你对Oracle体系结构的理解比如实例Instance和数据库Database的区别SGA和PGA的作用redo log和undo表空间的设计。如果你在真实的项目里接触过Oracle这些概念会非常熟悉。6.2 国产数据库的崛起与选型逻辑国产数据库是近年笔试热点这批也不例外。它问的是在一个政企类项目中如果有自主可控的要求你会选择哪款国产数据库替代MySQL为什么这道题我完整写了达梦数据库和人大金仓两个方向。达梦数据库在架构上对标Oracle兼容性好适合从Oracle迁移的老系统人大金仓KingbaseES则对PostgreSQL和Oracle的兼容性都不错在信创项目中落地案例较多。同时我还提到了GaussDB在华为生态里的优势以及OceanBase、TiDB这类分布式数据库在高并发场景下的选型思路。答题的核心逻辑不在于你背下了多少产品名而在于你是否有选型方法论。我给出的框架是先看兼容性从存量系统迁移的难易程度再看架构集中式还是分布式然后看生态和社区活跃度最后结合团队的技术栈熟悉度做决策。框架比结论重要得多这也是面试官更希望看到的思维模式。6.3 数据库工具链从dbx到Navicat笔试题里有一道选择题涉及数据库客户端工具的功能对比。它是通过dbx数据库工具这一类热词引申出来的考察你知不知道这些工具各有什么特点。dbx作为一个数据库管理工具核心功能集中在连接管理、SQL编辑、数据导入导出等方面Navicat和DataGrip则是更常见的全平台客户端DBeaver在开源场景里使用率很高而命令行侧的mysql-client和psql虽然不如图形界面友好但在自动化脚本和服务器上没有图形界面的环境里依然是首选。这类题本身不难但它背后反映出的信号是招聘方希望候选人不只是会用Navicat还要具备在多样化工具链下工作的能力。对于笔试我建议你在简历里写到的工具都亲手操作一遍至少知道它支持哪些数据库类型、大致的界面布局和核心功能入口这样遇到工具类选择题根本不用猜。6.4 向量数据库与时序数据库新方向进入考纲向量数据库相关的题目出现在这次笔试里让我有些意外但仔细一想又在情理之中。随着大模型和RAG应用的火热向量数据库的岗位需求在暴涨笔试中自然就多了向量检索、相似度计算、Embedding存储这类概念题。哪怕你目前的工作根本不涉及向量数据库我也建议你对它的核心思想向量索引、近似最近邻搜索、与关系型数据的结合方式有个基本认知。时序数据库也一样它考察的是时序数据库的数据库结构怎样设计。热词里反复出现这个问题说明时序数据的场景监控指标、IoT传感器、金融行情在业务中越来越普遍。时序数据库的核心设计思路是按时间维度分区、数据压缩率高、支持海量高并发写入、聚合查询能力强。如果你能答出这些特点和它与传统关系型数据库的差异在生态题上会非常加分。7. 备战建议拿到一批笔试后的针对性复习路径最后这部分不是总结是我自己从这次笔试里提炼出来的一套复习方法算是给准备春招的朋友一个参考方向。如果你手头已经拿到类似批次的笔试通知可以从以下几个方面做重点投入性价比会非常高。第一SQL必须练到条件反射级别。笔试里的SQL题不会给你太多思考时间尤其是窗口函数和多表关联的组合题考场上临时推演会很紧张。建议把力扣的数据库题库中等难度以上的题都刷一遍重点练窗口函数、连续性问题、分组TopN、留存率计算这几类这些都是笔试里的常客。第二锁和MVCC必须能用语言讲出来。死记硬背最大的问题是遇到场景题你会发现知识点对不上号。我自己的方法是把事务并发问题当成一个角色扮演游戏每次读一条SQL就模拟一下InnoDB底层会加什么锁、读哪个版本、在什么条件下会不会阻塞。这个习惯坚持两三个星期应对笔试里的锁机制题就会轻松很多。第三执行计划必须亲手看过。如果你没有现成的慢SQL可以找一个线上或本地环境用EXPLAIN分析几条不同写法的查询看看type、rows、Extra这些字段如何变化。看得多了笔试里给出一条SQL的执行计划你就能一眼看出问题所在。第四对生态类题目的准备不要过度焦虑。像向量数据库、国产数据库这类内容做到知道是什么、能说出选型思路的程度就够用了不需要花大量时间深入研究。真正的复习重心还是要放在SQL和原理题上这两块能保住80%的分数。最后再分享一个我在考场上用的小技巧遇到拿不准的场景判断题先把题目里的隔离级别和索引情况圈出来再作答。很多看似复杂的并发题只要确定这两个前提答案方向基本就不会跑偏。考试也好做项目也罢数据库岗拼到底的还是对底层机制的清晰认知和对实际场景的准确判断。希望这份复盘对你有用。