2023年度小满意春招数据库岗第二批笔试复盘考点拆解与备赛思路春招季帮一个学弟看了一套数据库岗的笔试题题目整体不偏不怪但覆盖面很广从经典SQL语法到事务隔离级别、从索引优化到国产数据库生态都有涉及。这套卷子虽然是2023年出的但里面考察的知识点放到现在依然很能打尤其是数据库同步、连接池、国产数据库适配这些方向几乎就是这几年数据库岗位面试的高频风向标。如果你正在准备数据库方向的校招或者社招这套题值得静下心来过一遍它的题型设计和考察逻辑比单纯刷LeetCode SQL题要完整得多。我自己看完这套卷子最大的感受是出题人明显不是想为难人而是想筛选出真正理解数据库运行机制、而不只是会写CRUD的候选人。整张卷子大概覆盖了基础SQL、索引优化、事务并发、存储过程、数据库架构设计、高可用方案、数据库同步、国产数据库兼容等几条主线。无论你主攻MySQL、Oracle还是PostgreSQL这套题的知识体系都是通用的一些题目还涉及了具体的场景化设计需要你在规定时间内给出一个相对完整的方案非常考验平时的积累。1. 试卷整体结构与考点分布1.1 题型构成与分值占比这份笔试卷子大概可以分为五个模块选择题/填空题、SQL编写题、事务与锁机制题、数据库设计题、综合架构题。从分值占比来看SQL编写和索引优化这两块加起来能占到40%左右事务隔离级别与锁机制占20%左右数据库设计占20%左右剩下的就是架构与国产数据库相关的开放性题目。这个分布其实很能说明问题基础扎实是底线设计能力和架构视野是加分项。选择题里有一道经典的“联合索引最左前缀”问题给了一个复合索引(a, b, c)问你下面哪些查询能命中索引。这种题刷过八股文的同学基本都能答对但有两道选择题我印象比较深一道是问“RR可重复读隔离级别下MVCC的可见性判断基于什么”另一道是问“InnoDB的间隙锁在什么条件下才会生效”。这两道题考察的不再是简单的背概念而是你能否把索引、锁、事务、隔离级别这几个知识点串起来理解它们在真实执行过程中的联动关系。SQL编写题里有一道“查每门课成绩排名前3的学生”看似简单但用窗口函数一行就能解决用普通SQL写就需要连表子查询来实现排名两种写法得分差距很大。这其实是在考察你平时写SQL的习惯——是条件反射地使用窗口函数还是只会最基础的GROUP BY和WHERE。1.2 出题思路与考察能力模型透过这套卷子能看出出题人想考察的是三个层次的能力。第一层是基本操作能力也就是你能不能熟练完成数据库的增删改查能不能写出正确高效的SQL知不知道索引在什么时候会失效。第二层是原理理解能力也就是你知不知道InnoDB为什么用B树事务隔离级别是怎么通过锁和MVCC实现的一条UPDATE语句在底层到底做了哪些事。第三层是架构设计能力也就是给你一个业务场景你能不能设计出合理的数据表结构能不能选择合适的高可用方案能不能评估主从同步延迟对业务的影响。这三个层次基本对应了数据库岗位日常工作的核心能力要求。如果你已经准备过一轮数据库基础做这套题的时候应该会觉得很顺畅因为这些题目都是“思考之后能答出来”的而不是靠死记硬背。反过来如果你连B树和哈希索引的区别都说不太清楚、对MVCC完全没有概念那这套卷子做起来就会非常吃力。整张卷子实际上是一面镜子把你的知识盲区映照得清清楚楚。2. 必考核心模块基础语法与索引优化实操2.1 SQL增删改查背后的执行细节按理说增删改查是数据库岗最基础的内容但很多人在笔试题里栽跟头恰恰是栽在这些“简单题”上。比如有一道题是写一条UPDATE语句把订单表里状态为“已支付”的订单金额在原基础上打九折。大部分人能写出UPDATE orders SET amount amount * 0.9 WHERE status 已支付但这个写法在真实业务里是有隐患的因为你不知道这个表有多大不知道有多少行会被更新更不知道这条语句会不会锁住整张表。在实际的数据库课程设计和项目开发中批量更新数据之前一定要先做影响行数评估。MySQL里可以先用SELECT COUNT(*)估算一下命中行数然后确认是否有合适的索引能支撑WHERE条件的快速定位。如果是大批量更新分批做、控制每批的影响行数或者用LIMIT子句配合循环处理都是常见的稳妥做法。笔试里虽然只是让你写一条简单的UPDATE但如果你能在答案里体现出对锁范围、索引利用、批量操作风险的思考这道题的得分会明显高于只写一条标准语句的答案。还有一个高频考点是INSERT和REPLACE的区别、INSERT IGNORE和ON DUPLICATE KEY UPDATE的区别。很多人在做excel导入数据库、数据同步这类场景时都会用到这些语法。笔试中会给你一张学生表和一张成绩表要求把成绩表中已存在的学生成绩更新、不存在的插入。如果你只会写“先DELETE再INSERT”虽然结果对但没有考虑自增主键的变化也没有考虑外键依赖在并发场景下还会产生间隙锁问题。正确的做法是用ON DUPLICATE KEY UPDATE或者MERGEOracle这种写法既原子又高效还不会产生主键漂移。2.2 索引失效场景与执行计划分析索引优化这块是数据库岗位笔试的重头戏几乎每套卷子都会有几道题是专门考察索引知识的。这套卷子里有一道题给出了一个订单表字段包括id、order_no、user_id、status、create_time问你下面的SQL为什么慢SELECT * FROM orders WHERE user_id 123 AND status 1 ORDER BY create_time DESC LIMIT 10。如果这个表只有一个主键索引那这条SQL必然是全表扫描因为没有任何索引能直接支撑user_id的等值过滤。如果建了(user_id, status)联合索引那status这一列对排序的帮助很有限因为联合索引的第二个字段无法直接用于避免文件排序。关于排序以这条SQL为例如果你建的是(user_id, create_time)联合索引那么WHERE user_id 123走等值查询后create_time天然就是有序的ORDER BY create_time就可以直接利用索引顺序避免额外的filesort。这是索引设计里一个很经典的“等值字段在前、排序字段在后”原则。笔试中经常会把这两类索引放一起做对比考察你到底有没有真正理解联合索引的列顺序是怎么影响查询计划的。常见的索引失效场景也是选择题里的高频考点。比如对索引列使用函数运算、隐式类型转换、LIKE前置通配符、OR条件连接非索引列、NOT IN操作这些都会导致索引失效。我见过很多人在笔试里栽在“隐式类型转换”这道题上比如字段类型是VARCHAR但查询条件传的是数字MySQL会先把字段转换为数字再比较导致索引无法使用。这种细节问题在oracle数据库里也有类似表现所以笔试中经常把不同数据库的索引行为放在一起作为干扰项。实操中遇到慢查询时我建议把工具链用起来。MySQL里用EXPLAIN看执行计划关注type字段从system到ALL的级别重点关注rows预估行数和Extra字段里是否出现Using filesort或Using temporary。Oracle里可以用执行计划查看工具或者用SQL Tuning Advisor。面试时如果你能描述出“我先用EXPLAIN看了执行计划发现走了全表扫描然后调整了索引设计加了联合索引之后查询时间从800ms降到了20ms”这样的真实排查过程这个能力肯定比背概念拿分多因为这是实打实的数据库SQL优化经验。2.3 索引设计的基本方法论索引设计不能只会“给WHERE条件的字段加索引”笔试中会给出更完整的业务场景要求你设计表结构和索引组合。有一个经典场景是电商订单查询用户需要按状态和时间范围查询订单列表同时后台需要按商家统计订单金额。这种场景下如果只建一个索引无论怎么建都很难同时满足两个查询路径。正确做法是分析两种查询的基数和访问模式用户端的查询通常是以user_id为等值条件再加上status和create_time作为筛选范围所以(user_id, status, create_time)联合索引是合理的后台按商家统计以merchant_id为等值条件需要根据时间范围做聚合建(merchant_id, create_time)联合索引更合适。当然索引不是越多越好每个索引都会拖慢写入性能占据存储空间所以还需要根据实际的慢查询日志来决定哪些索引真正值得保留。笔试里有一道题专门问“数据库开启审计引起索引争用”的问题这个题目出得很专业。数据库审计功能会记录大量SQL访问信息导致高频率的写入操作占用系统资源进而让索引页的争用加剧。解决方案通常是综合考虑审计粒度、采样比例以及对大量审计数据做分区归档尽量把审计写入的影响控制在可接受范围内。这道题考的是运维实践中对数据库运行机制的深度理解而不仅仅是SQL编写能力。3. 事务隔离级别、死锁与并发控制3.1 四种隔离级别与MVCC实现原理事务隔离级别是数据库岗位笔试的必考内容而且几乎每年都会出现在笔试题里。这套卷子用了一个很典型的场景一个在线转账系统有两个并发事务分别需要读取账户余额并更新余额问你分别用不同隔离级别时会出现什么问题。读未提交会导致脏读读已提交解决了脏读但会有不可重复读可重复读解决了不可重复读但可能会有幻读InnoDB通过间隙锁在RR级别下基本解决了幻读串行化则牺牲并发性能换取完全隔离。MySQL InnoDB默认的隔离级别是RRREPEATABLE READ而Oracle的默认隔离级别是READ COMMITTED这一点很多人容易记混。在MySQL的RR级别下MVCC的可见性判断是基于事务启动时或第一次读取时创建的read view同一个事务内多次查询看到的数据是一致的。而在READ COMMITTED级别下每次查询都会生成新的快照所以两次查询之间如果其他事务提交了当前事务就会看到新数据这就是不可重复读。笔试题里更深一步的问题是让你画出MVCC在RR级别下的可见性判断流程。里面关键数据结构是undo log版本链和read view的四个核心属性creator_trx_id、up_limit_id、low_limit_id、trx_ids列表。一个数据行的某个版本是否对当前事务可见就看这行的trx_id满足什么条件如果trx_id等于creator_trx_id说明是自己修改的、可见如果trx_id小于up_limit_id说明是已提交事务、可见如果trx_id大于low_limit_id说明是未来事务、不可见如果trx_id在trx_ids列表中说明是未提交并发事务、不可见。这套规则理解透了MVCC相关的题基本就能全对。3.2 数据库死锁的产生、检测与处理死锁在笔试题里出现频率非常高因为它是并发控制中最常遇到的真实问题。这套卷子用了一个经典的“转账互等”场景事务A先更新账户1再更新账户2事务B先更新账户2再更新账户1两个事务各持一把锁等待对方的锁就产生了死锁。解决办法通常是让所有事务按同一顺序访问资源或者使用数据库的死锁检测机制强制回滚其中一个事务。InnoDB处理死锁的机制是死锁检测wait-for graph一旦检测到循环等待就选择回滚代价较小的事务。但死锁检测本身有性能开销高并发场景下检测成本会显著提升所以很多团队会使用锁超时参数来兜底比如MySQL的innodb_lock_wait_timeout。在实际项目里我发现最常见的死锁场景其实是批量操作两个事务都先查后写先查询出来的结果集互相交集然后分别更新对方锁定的行这种隐蔽死锁在笔试中更难答对。笔试答案里如果你能写出来“死锁产生的四个必要条件互斥、持有并等待、不可剥夺、循环等待”并逐一对照场景分析面试官会觉得你的理论基础很扎实。但更重要的是后面那部分如何通过调整SQL顺序、缩小事务范围、合理设计索引来减少锁冲突从而降低死锁概率这才是真正的数据库并发调优能力。3.3 数据库并发锁的粒度选择数据库并发锁也是一个常见的考点考察范围覆盖表级锁、页级锁、行级锁以及乐观锁和悲观锁的使用场景。InnoDB提供行级锁但这并不意味着所有操作都走行锁如果WHERE条件没有索引支撑优化器可能会选择全表扫描行锁升级为表锁并发度会急剧下降。所以给高频更新场景的WHERE条件建立合适索引就是在保护行锁的粒度。笔试里有一道很有意思的题一张商品库存表每次秒杀扣减库存时怎样保证不超卖很多人的第一反应是给查询加锁或者使用悲观锁SELECT ... FOR UPDATE。这确实能解决问题但在高并发场景下会有比较明显的性能瓶颈。更高效的方案是使用乐观锁UPDATE inventory SET stock stock - 1 WHERE product_id ? AND stock 0通过受影响行数判断是否扣减成功。这种方案不需要显式加锁既能避免超卖性能也更好。当然它也有缺点如果冲突频繁大量更新会失败重试。在真实秒杀系统里通常还会配合限流、缓存、消息队列等手段来削峰填谷数据库层面只是最后一道防线。4. 连接池、主从同步与高可用方案4.1 连接池的工作机制与参数考量数据库连接池在笔试中也是高频考点尤其是问“为什么不能用原生的数据库连接必须要用连接池”。这道题的背后是每次新建数据库连接都要经历TCP握手、身份认证、权限校验等步骤开销很大而连接池可以把建立好的连接复用起来降低连接创建和销毁的开销。笔试题中会给你具体的业务流量要求估算连接池大小。比如核心业务QPS是5000平均每个事务执行时间为20ms高峰期每个请求需要占用连接的时间是30ms。这套估算的思路是单连接每秒最大处理能力约为 1000ms / 30ms ≈ 33个请求要想支撑5000QPS理论上需要的连接数约为 5000 / 33 ≈ 152 个。但实际项目里不能按这个平均值估算还要考虑长事务、慢查询、网络抖动等因素所以通常会再乘以一个冗余系数同时设置一个上限防止数据库被连接数压垮。MySQL里的max_connections也要同步检查如果连接池最大连接数超过了数据库侧的上限排队等待反而会造成连接泄露。连接池的关键参数里initialSize、minIdle、maxActive、maxWait、timeBetweenEvictionRunsMillis这几个是必须能说清楚含义的。HikariCPSpring Boot默认连接池里更重要的是maximumPoolSize和connectionTimeout的配合maximumPoolSize设置太大不一定是好事因为每个连接背后都有一个数据库服务端线程连接数过多会导致上下文切换开销变大典型的推荐策略是宁可排队等待连接也不要把连接数无限调大。4.2 主从复制原理与数据同步延迟这套卷子的综合题里有一道要求设计一个读写分离方案并阐述主从复制的原理。我建议背清楚MySQL主从复制的完整流程主库在事务提交前把变更写入binlog从库的IO线程拉取binlog并写入relay log从库的SQL线程读取relay log并在本地重放最终实现数据同步。MySQL 5.7以后支持并行复制从库可以通过多个SQL线程并行应用不同数据库或不同事务的binlog大幅降低同步延迟。笔试中追问最多的是“从库延迟太大怎么办”。这个问题没有标准答案但考察的是你有没有实际排查经验。常见的原因有三种从库硬件配置不如主库、主库写入压力过大导致binlog产生速度高于从库应用速度、从库上有大查询占用了IO资源。如果你想在答案里体现出深度可以补充说用半同步复制semi-sync replication来保证主库提交后至少有一个从库收到了binlog从而降低数据丢失风险但这会增加主库的提交延迟需要根据业务场景来权衡。主从切换也是一道高频题尤其是“主库宕机后如何把从库提升为新的主库”。从原理上讲需要确认从库的relay log已经全部应用完成、补全与主库的差异数据然后提升从库为可写状态并通知应用切换数据源。实际生产环境中通常会使用MHA、Orchestrator等工具来管理切换流程做到秒级或分钟级自动化切换。如果你能在笔试中画出这个流程的主线和风险点思路清晰程度会比只知道“有一个MHA工具”高出不少。4.3 数据库同步工具与国产数据库适配最近两年“数据库同步”这个词在笔试题里越来越常出现尤其是在国产数据库替换的大背景下。此前有热词包括“数据库同步软件”“数据库同步工具”“nacos适配华为GaussDB数据库”等它们本质上都指向同一个技术方向不同数据库之间的数据迁移和实时同步。笔试中经常给出一个场景需要把Oracle数据库同步到达梦数据库或者把MySQL同步到人大金仓数据库问你用什么方案。这里面的核心链路通常是基于日志解析的同步工具如Oracle的OGG或基于binlog的Canal把源库的变更解析出来再通过消息队列或者自定义适配层写入目标库。这里有一个很大的技术点源库和目标库的数据类型、序列/自增主键机制、存储过程语法都有差异所以同步过程并不只是简单的复制数据还需要做类型映射和SQL兼容改造。比如达梦数据库总体上兼容Oracle的很多语法但事务处理、并发控制、错误码等细节依然不同不能无脑替换。笔试里如果你能提到“先用工具做全量同步再通过日志增量同步最后做数据校验和灰度切换”这个三层流程基本上就能拿下这道题了。国产数据库方向这几年非常热门达梦数据库、人大金仓、GaussDB、Doris、OceanBase等都出现在热搜词里。笔试虽然不会要求你深入原理但很可能会问你知道哪些国产数据库、它们分别有什么特点、和MySQL/Oracle最大的差异是什么。对求职者来说掌握基础概念和差异化能力是非常重要的比如知道Doris偏向OLAP分析场景GaussDB在分布式事务上有自己的实现方案达梦数据库与Oracle的兼容性较好等。最好能回答出“我们在某个项目里把某个场景从MySQL迁移到达梦中间遇到了SQL方言不兼容、自增主键做序列适配等问题”这种实际经验在面试中是妥妥的加分项。5. 数据库设计、慢查询排查与备考建议5.1 从需求到建表的完整设计流程笔试中的数据库设计题通常不会让你设计一个极其复杂的系统而会给你一个中等规模的业务场景。这套卷子里有一道题是做“在线课程管理系统”的表结构设计包含学生、课程、选课记录、教师、成绩等实体要求你画出ER图并规划主要索引。这道题表面上是设计题实际上考察的是你对范式理论、主外键关系、索引设计、时间字段处理的综合运用。这类题最容易犯的错误是过度设计给每张表都加十几个冗余字段。面试官更希望看到的反而是简洁的模式学生表和学生课程关系表分开课程表单独维护课程信息成绩字段放到选课关系表里而不是单独建一张成绩表这是最典型的三范式设计。但我需要额外提醒一句大厂真实业务中会大量采用反范式设计来提高查询性能所以笔试中的设计题建议你先按范式设计再提出“为了查询性能可以在XX场景下做冗余”这类思考这样既展示了你对范式的掌握也体现了工程思维。时间字段的设计也是一道暗坑题。业务上经常需要记录创建时间和更新时间MySQL里可以用create_time DATETIME DEFAULT CURRENT_TIMESTAMPupdate_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP这是比较省心的做法。但如果你设计的是大规模分布式系统日期字段使用字符串还是时间戳都需要仔细权衡。另外在线课程系统的成绩记录要考虑同一个学生可能重修同一门课所以唯一索引不能简单落在(student_id, course_id)上而是要把学期字段也加入联合唯一索引或者改用选课记录ID做唯一性约束。这种细节就是你跟其他候选人拉开差距的地方。5.2 实时查询慢SQL的排查思路数据库岗笔试里经常会出现一道“某条SQL在生产环境突然变慢你怎么排查”的开放式问题。这道题没有固定答案但回答得好坏非常能体现实战经验。我总结过的排查路径一般是这样的先看数据库整体负载是否异常再看这条SQL是否发生了变化然后看相关表的统计信息是否过期最后看执行计划是否发生了劣化。在真实环境中“昨天还挺好用的SQL今天突然变慢”最常见的原因是统计信息过期或者新增了大量数据后优化器选择的执行计划走偏了。比如Oracle里会使用s ELECT * FROM TABLE(DBMS_STATS.GATHER_TABLE_STATS(...))重新收集统计信息MySQL里则是ANALYZE TABLE或者调整优化器策略。另一种情况是索引失效某天有人修改了表结构添加了一个新的字段或者调整了字段类型导致SQL走原来的索引时报类型转换错误退化成了全表扫描。这些排查过程用大白话说就是先看全局、再看单条、然后看执行计划、最后看统计信息与索引状态层层缩小范围。慢查询日志也是一个很实用的工具很多数据库都支持记录执行时间超过阈值的SQL。在日常工作中定期分析慢查询日志、把高频慢SQL整理出来逐一优化是DBA和开发工程师的基本功。笔试如果问你“如何定位慢查询”你一定要提到慢查询日志、EXPLAIN/执行计划分析、状态计数器比如Innodb_row_lock_current_waits、以及PROFILING做单条SQL耗时拆解。如果把这几个点说全了回答的系统性会比只回答一个EXPLAIN强非常多。5.3 数据库课程设计驱动的学习路径很多在校生会把“刷题”作为备考数据库岗位的主要方式但我个人觉得笔试只是第一关真正决定你能不能拿到Offer的是你能不能把知识点落到实践中。热词里频繁出现的“数据库课程设计”其实是一个很好的起点如果你认真做一个课程设计从需求分析、ER图设计、建表、写SQL、做索引优化、写存储过程到把系统部署起来你的动手能力会得到系统性的锻炼这比刷一百道选择题都有价值。课程设计里最容易踩的坑是“只关注功能实现不关注数据量和查询性能”。比如课堂作业里数据量可能只有几百行索引的作用完全体现不出来但面试官一追问“如果这张表有一千万行你的SQL还能跑得动吗”就会露馅。所以做课程设计的时候可以主动造一些大数据量测试数据比如用存储过程生成随机数据然后练习用EXPLAIN看执行计划观察索引有没有被命中观察排序有没有走filesort。这种主动加练的意识会让你在笔试中遇到偏实践的问题时特别占便宜。如果你已经有一定基础推荐再做一次“数据库同步小实验”开两个MySQL实例配置好主从复制然后在主库里插入数据观察从库的同步延迟再把binlog格式调整为ROW模式看看同步行为有什么变化最后试着模拟主库宕机手动把从库提升为主库。这个实验做完你对主从复制、binlog、数据同步的理解会直接从“背过的八股文”变成“真正消化过的知识”这比任何培训班都有效。5.4 工具链从连接工具到设计工具的全套储备最后想聊聊热词里反复出现的数据库工具。像dbx数据库工具主要解决的是多种数据库的集中管理问题因为日常工作中你可能会同时面对MySQL、Oracle、PostgreSQL、达梦、人大金仓等多种数据库不同的连接方式、不同的管理界面会让开发效率非常低。dbx这类工具的价值就在于统一管理、批量操作、可视化查看表结构和SQL执行结果热词中提到的“dbx数据库工具官网”“dbx数据库安装使用”都说明这个工具在开发者中已经有了一定关注度。不过笔试题实际上很少直接考某个具体工具怎么操作它更想考察的是抽象能力你是否知道数据库连接的基本参数地址、端口、服务名/SID、用户名、密码是否知道如何通过工具执行SQL脚本、导出数据库脚本、批量导入数据。比如热词“idea导出数据库脚本”本质上是让你说出“如何从开发工具连接数据库并导出建表语句和数据”这个操作本身并不复杂但它背后对应的是你对数据库结构、字符集、约束、索引、触发器、存储过程等对象的整体理解。笔试中如果真的出现这种题目反而是在考察你日常开发流程的规范程度。另外提一句“数据库死锁”“数据库并发锁”这类问题很多工具比如Performance Schema、sys schema其实都可以辅助排查。你在笔试或者面试中如果能主动提到“我会用performance_schema的data_lock_waits表查看锁等待信息”比你只回答“死锁就是事务互相等锁”要具体得多。工具是死的但理解是活的。真正的高手从来不是背下来某个工具的所有按钮而是无论拿到什么工具都能基于自己对数据库原理的理解快速定位问题。5.5 备赛节奏与应试技巧总结根据我自己带人和参加招聘的经验数据库岗笔试准备可以按三个阶段来推进。第一阶段是基础扫盲把SQL增删改查、索引、事务隔离级别、锁机制、存储引擎这些核心概念过一遍做到能不看资料复述出MVCC的可见性判断流程能画出InnoDB B树的组织结构。第二阶段是项目实战选一个开源项目或者自己做一个小型管理系统把数据库设计和SQL优化真正用起来重点练EXPLAIN看执行计划、慢查询日志分析、高并发场景下的更新语句设计。第三阶段是模拟冲刺找几套往年大厂的数据库笔试题限时2小时完成做完后逐题分析考察点找出自己的薄弱环节集中突破。应试技巧方面我建议先做SQL编写题再做数据库设计题最后做综合架构题。因为SQL题得分确定性最高设计题需要完整思路架构题是加分项但最耗时间。审题非常重要很多人在“查每门课成绩排名前3”这种题目上失分不是因为不会写而是没注意到要“按课程分组排名”随手就写了全局ORDER BY LIMIT 3。还有一道题要求“更新时不能影响其他事务”有些人直接回答用READ UNCOMMITTED实际上题目想要的是行锁或者乐观锁控制这种错误就是典型的审题不仔细。最后一个小建议如果你有条件尽量把每个知识点都动手做一遍。装了MySQL就自己建用户、建库、改表结构、导出数据库脚本再试试给一张百万行的表加索引看看查询时间的变化。装了达梦数据库或人大金仓数据库也一样体验一下国产数据库在语法和运维工具上的差异。数据库岗位的价值从来不是你会多少个工具而是你能不能在数据出问题时快速定位根因并设计出合理的解决方案。这套笔试只是起点真正拉开差距的是你平时积累的深度和广度。