MySQL 笔试题练习及答案一每年招聘季总有一批人在数据库笔试环节栽跟头。不是不会写 SQL而是题目里埋的坑太隐蔽——索引失效、隐式类型转换、聚合函数与 NULL 的纠缠、事务隔离级别的边界情况这些在真实业务里可能被 ORM 框架挡住的问题到了笔试卷面上全暴露出来。我这些年带过不少新人也帮朋友做过模拟面试发现一个规律MySQL 笔试题考的不是你会不会用数据库而是你对底层行为的预判能力。这篇内容就是围绕这个核心展开的把常见的笔试题型拆开揉碎讲清楚每道题背后的原理、出题人的意图、以及实际工作中对应的场景。不管你是刚学完 SQL 基础语法的新手还是工作两三年想跳槽的老手都能从里面找到对自己有用的东西——新手可以当作系统复习的路线图老手可以拿来查漏补缺看看自己是不是也有那些“以为懂了其实没懂”的知识盲区。1. 笔试题型全景与出题逻辑拆解1.1 为什么笔试题总爱考这些“偏门”知识点很多人做完笔试题会有一种感觉平时写业务代码根本用不到这些啊。这话对了一半。业务开发中确实很少手写复杂的多表关联也很少直接操作索引提示但笔试题考的是你对数据库行为的理解深度。出题人心里很清楚一个候选人如果连COUNT(*)和COUNT(column)的区别都说不清楚那他在写分页查询时就很可能踩到性能坑如果不知道NULL在比较运算中的特殊行为那写出来的WHERE条件就可能悄悄漏掉数据。我观察下来MySQL 笔试题的考点分布大致是这样的SQL 语法与查询逻辑占四成左右索引与执行计划占两成半事务与锁占两成剩下的是存储引擎、字符集、权限管理等杂项。这个分布和实际工作中遇到问题的频率基本吻合——查询写不对是日常索引没建好是性能瓶颈的根源事务理解不到位就是数据一致性的定时炸弹。1.2 从题型反推出题人的考察意图拿到一道笔试题别急着写答案先想一个问题出题人为什么这么问。比如一道经典的题目“以下哪个 SQL 语句能查出表中第二高的薪水”看起来是考ORDER BY和LIMIT实际上出题人想确认的是你有没有考虑重复值的情况、有没有考虑表中数据不足两条的情况、以及你知不知道LIMIT的偏移量写法。这三个点分别对应了DISTINCT的使用、IFNULL的处理、以及LIMIT offset, count的语法细节。再比如题目给出一张表结构和几条数据问某个查询的结果是什么。这种题表面考的是 SQL 执行结果深层考的是你对执行顺序的理解——FROM先于WHEREWHERE先于GROUP BYGROUP BY先于HAVINGSELECT里的别名在WHERE中不能用但在ORDER BY中可以用。这些顺序搞不清楚做题就只能靠猜。1.3 备考策略从“会写”到“写对且写快”备考 MySQL 笔试我的建议是分三步走。第一步把基础语法过一遍重点是JOIN的各种变体、子查询的写法、聚合函数的行为。第二步专门练“读题”能力拿到题目先圈出关键词——有没有“去重”、有没有“为空”、有没有“排序后取第几”。第三步限时模拟因为笔试是有时间压力的很多错误不是不会而是想太快导致遗漏条件。这里有个很实用的技巧做完每道题后自己给自己出变体。比如原题是“查第二高”你就想“如果改成查第三高呢”“如果表里只有一条数据呢”“如果有多个相同的最高值呢”。这种自我追问能帮你把知识点串成网而不是孤立地记答案。2. 查询类笔试题的核心陷阱与破解方法2.1 聚合函数与 NULL 的纠缠COUNT 的三种写法差异先看一道高频题表employees中有id、name、department三个字段其中department允许为NULL。问SELECT COUNT(*), COUNT(department), COUNT(1) FROM employees的结果分别是什么。这道题的答案是COUNT(*)统计所有行数COUNT(department)只统计department不为NULL的行数COUNT(1)和COUNT(*)结果相同。很多人知道结论但说不清原因。底层逻辑是这样的COUNT(*)和COUNT(1)走的是“统计行数”的路径优化器会选最小的索引来扫描而COUNT(column)需要逐行判断该列是否为NULL非NULL才计数。所以如果department上有索引且NULL值很少COUNT(department)可能反而更快因为它扫的索引更窄。实际工作中这个知识点直接对应一个场景统计某个字段的“有效填写率”。如果你写COUNT(department) / COUNT(*)得到的就是非空占比。但如果你误写成COUNT(IFNULL(department, 0))那就全算成有效了数据就失真了。注意SUM()、AVG()、MAX()、MIN()这些聚合函数同样会忽略NULL。AVG(column)的分母是非NULL的行数不是总行数。这一点在算平均分、平均薪资时特别容易出错。2.2 子查询与 JOIN 的等价改写什么时候该用哪个笔试题里经常出现这样的要求“查出每个部门薪资最高的员工信息”。标准解法有两种一种是关联子查询一种是JOIN加子查询。先看关联子查询的写法SELECT e.* FROM employees e WHERE e.salary ( SELECT MAX(salary) FROM employees WHERE department e.department );这个写法逻辑清晰但有个隐患如果同一个部门有两个人薪资相同且都是最高两条都会查出来。如果题目要求“每个部门只取一条”那就得加GROUP BY或者用窗口函数。再看JOIN的写法SELECT e.* FROM employees e INNER JOIN ( SELECT department, MAX(salary) AS max_salary FROM employees GROUP BY department ) t ON e.department t.department AND e.salary t.max_salary;两种写法在结果上等价但执行效率可能不同。关联子查询在外层表数据量大时每一行都要执行一次子查询虽然优化器可能会做物化优化但不如JOIN写法稳定。实际开发中我更倾向于JOIN写法因为执行计划更可控而且方便后续加过滤条件。2.3 LIMIT 分页的经典坑偏移量大了怎么办“查出第 10001 到 10100 条记录”这种题考的是LIMIT的偏移量写法LIMIT 10000, 100。但出题人往往还会追问一句这样写有什么性能问题答案是LIMIT 10000, 100会先扫描前 10000 条记录然后丢弃只返回后面的 100 条。偏移量越大扫描的行数越多性能越差。优化思路有两种。第一种是用覆盖索引加子查询SELECT * FROM employees WHERE id (SELECT id FROM employees ORDER BY id LIMIT 10000, 1) ORDER BY id LIMIT 100;这里的前提是id是主键且有索引子查询只扫索引不扫全表拿到起始id后再用主键范围查询取数据。第二种是记录上一页的最大id下一页从id last_id开始查这就是所谓的“游标分页”。第二种方案在无限滚动场景下是标配但缺点是没法跳页。提示笔试答题时如果只写LIMIT 10000, 100可能拿不到满分最好把优化思路也写上哪怕只是提一句“大偏移量建议用延迟关联或游标分页”。2.4 多表关联中的笛卡尔积陷阱一道典型的坑题表 A 有 3 条记录表 B 有 4 条记录问SELECT * FROM A, B返回多少条。答案是 12 条笛卡尔积。如果题目再加一个条件“A 和 B 通过某个字段关联但关联字段有重复值”那结果可能既不是 3 也不是 4而是大于等于 3 的某个数。这类题考的是你对关联键唯一性的敏感度。实际工作中笛卡尔积是慢查询的头号嫌疑犯。我排查过的慢 SQL 里至少三成是因为漏写了关联条件或者关联条件写错导致的行数爆炸。笔试题里遇到多表关联养成一个习惯先确认关联字段在两张表里是不是唯一的如果不是想清楚重复值会不会导致结果翻倍。3. 索引与执行计划类题目深度解析3.1 最左前缀原则为什么你的索引没生效这是索引类笔试题的必考内容。给一个联合索引idx_abc(a, b, c)问以下哪些查询能用上索引WHERE a 1、WHERE b 2、WHERE a 1 AND c 3、WHERE a 1 AND b 2 AND c 3。答案是第一个和第四个能用第二个完全用不上第三个只能用上a这一列。原理在于 B 树索引的排序方式联合索引先按a排序a相同再按b排序b相同再按c排序。所以查询条件必须从最左边的列开始连续匹配中间断了就只能用到断点之前的列。WHERE a 1 AND c 3跳过了b所以c用不上索引只能靠a过滤后再回表逐行判断c。但这里有个容易混淆的点WHERE a 1 AND c 3虽然c用不上索引查找但如果查询的列都在索引里覆盖索引优化器可能选择全索引扫描而不是回表。所以严格来说不是“完全用不上”而是“用不上索引的快速定位能力”。笔试答题时如果遇到判断题要看选项的具体措辞。3.2 隐式类型转换字符串字段传数字的后果看这道题表users中phone字段是VARCHAR(20)类型并且建了索引。执行SELECT * FROM users WHERE phone 13800138000问索引是否生效。答案是不生效因为等号右边是数字类型MySQL 会把字符串列转成数字再比较转换发生在列上索引就失效了。这个坑在实际开发中极其常见。前端传参有时候是字符串有时候是数字后端如果不做类型校验直接拼进 SQL就可能触发隐式转换。更隐蔽的是这种查询不会报错结果也“看起来对”但性能可能差几十倍。我见过一个线上接口QPS 一高就超时最后定位到就是手机号查询没加引号。反过来如果字段是INT类型查询条件传了字符串123MySQL 会把字符串转成数字转换发生在常量侧索引仍然生效。所以规则可以总结为转换发生在列上就失效发生在常量上就没事。3.3 EXPLAIN 关键字段解读type 和 Extra 怎么看笔试题有时会给一段EXPLAIN的输出让你判断查询性能好坏。重点看两个字段type和Extra。type的优劣顺序大致是system const eq_ref ref range index ALL。看到ALL就是全表扫描基本可以判定需要优化看到index是全索引扫描比全表好一点但也不理想ref和range是常见的好状态。Extra字段里Using index表示覆盖索引不需要回表这是好现象Using where表示在存储引擎层过滤后还需要在 Server 层再过滤Using filesort表示需要额外排序如果数据量大就是性能瓶颈Using temporary表示用了临时表常见于GROUP BY和DISTINCT操作。有个细节很多人忽略Using filesort不一定真的用磁盘文件排序如果排序数据量小会在内存里完成。但笔试答题时看到这个词就应该警觉说明排序没有利用索引的有序性。3.4 索引失效的六种典型场景速查除了隐式类型转换还有几种常见的索引失效场景我整理成表格方便对照记忆场景示例失效原因对索引列做运算WHERE id 1 10列参与了计算无法用索引定位对索引列用函数WHERE DATE(create_time) 2024-01-01函数作用在列上索引值被改变前导模糊匹配WHERE name LIKE %张无法确定前缀只能全扫OR 连接非索引列WHERE a 1 OR b 2b 无索引优化器可能放弃索引走全表使用 NOT IN / !WHERE status ! 1否定条件通常无法有效利用索引联合索引跳过最左列索引(a, b)查询WHERE b 2违反最左前缀原则这张表建议直接背下来笔试选择题里出现频率极高。实际开发中写WHERE条件时也可以拿它当检查清单过一遍。4. 事务、锁与存储引擎类题目实战4.1 事务隔离级别与脏读幻读的对应关系笔试题里关于事务的经典问法“在 RC读已提交隔离级别下以下哪种现象不会出现”选项里通常有脏读、不可重复读、幻读。答案是脏读不会出现不可重复读和幻读都可能出现。四个隔离级别的行为对照如下隔离级别脏读不可重复读幻读读未提交可能可能可能读已提交不可能可能可能可重复读不可能不可能可能InnoDB 下基本避免串行化不可能不可能不可能这里有个容易扣分的细节MySQL 的 InnoDB 引擎在可重复读级别下通过间隙锁Gap Lock在很大程度上避免了幻读所以严格说“幻读”在 RR 级别下也不是必然出现。但笔试标准答案通常还是按理论表格来答题时如果遇到判断题要看题目有没有特别说明“InnoDB 引擎”。4.2 行锁与表锁的触发条件“以下哪个操作会加表锁”这类题考的是锁的粒度判断。InnoDB 默认是行锁但以下情况会升级为表锁或者锁住更多行WHERE条件没有走索引时行锁会退化为表锁使用LOCK TABLES语句显式加表锁执行ALTER TABLE等 DDL 操作时。另外SELECT ... FOR UPDATE在没有索引的情况下也会锁全表。实际工作中这个知识点关系到并发性能。我遇到过一个问题两个事务同时更新同一张表的不同行按理说行锁不冲突但实际却互相等待。排查后发现WHERE条件用的字段没有索引行锁退化成了表锁。加索引后问题消失。所以笔试里看到“行锁变表锁”的选项优先考虑索引缺失这个原因。4.3 InnoDB 与 MyISAM 的核心差异对比存储引擎的对比题几乎是必考。核心差异集中在几个维度事务支持InnoDB 支持MyISAM 不支持、锁粒度InnoDB 行锁MyISAM 表锁、外键InnoDB 支持MyISAM 不支持、崩溃恢复InnoDB 有 redo log 支持MyISAM 没有、全文索引早期 MyISAM 支持而 InnoDB 不支持MySQL 5.6 之后 InnoDB 也支持了。笔试答题时如果问“如何选择”标准答案是需要事务和并发写入选 InnoDB纯读场景且对事务无要求可以考虑 MyISAM但实际生产中基本默认 InnoDB。4.4 MVCC 机制简析为什么可重复读能生效MVCC多版本并发控制是 InnoDB 实现可重复读的核心机制。每行记录有两个隐藏字段DB_TRX_ID最后修改该行的事务 ID和DB_ROLL_PTR指向 undo log 的回滚指针。读取数据时InnoDB 根据当前事务的 Read View 判断哪个版本可见。Read View 里记录了活跃事务 ID 列表如果某行的事务 ID 在活跃列表里说明该版本是未提交的就顺着回滚指针找上一个版本。笔试题里可能问“可重复读级别下事务 A 先查询一次事务 B 修改并提交事务 A 再查询结果是否变化”答案是不变因为事务 A 的 Read View 在第一次查询时就确定了后续查询复用同一个 Read View。这个机制保证了同一事务内多次读取结果一致。但要注意如果是当前读SELECT ... FOR UPDATE读的是最新版本不受 Read View 限制。5. 常见易错点与考场实战技巧5.1 那些年我们踩过的 SQL 语法坑笔试里有些错误不是逻辑问题纯粹是语法细节没记牢。比如GROUP BY之后SELECT的列必须是分组列或者聚合函数这在ONLY_FULL_GROUP_BY模式下会直接报错比如HAVING和WHERE的区别WHERE在分组前过滤HAVING在分组后过滤HAVING里可以用聚合函数而WHERE不行再比如UNION和UNION ALL的区别前者去重后者不去重性能上UNION ALL更快。还有一个高频坑ORDER BY后面跟数字表示按第几列排序而不是按常量值排序。ORDER BY 1是按第一列排不是按数字 1 排。这个语法在笔试里经常用来迷惑人。5.2 时间与字符串函数的返回值陷阱日期函数是笔试题的常客。NOW()返回当前日期时间CURDATE()只返回日期DATE_FORMAT()用于格式化。坑点在于WHERE create_time 2024-01-01这种写法如果create_time是DATETIME类型实际上比较的是2024-01-01 00:00:00当天的其他时间数据查不出来。正确写法是WHERE create_time 2024-01-01 AND create_time 2024-01-02或者用DATE(create_time) 2024-01-01但后者会导致索引失效。字符串函数里CONCAT()遇到NULL返回NULL这个行为经常被忽略。CONCAT(a, NULL, b)的结果是NULL而不是ab。如果要做空值兼容得用CONCAT_WS()或者IFNULL()包一层。5.3 笔试答题节奏与检查清单最后分享一个考场上的实操建议。拿到卷子先扫一遍把题目分成三类一眼有思路的、需要想一下的、完全没头绪的。先做第一类保证基础分拿稳再做第二类控制好时间第三类留到最后能写多少写多少。SQL 手写题要注意格式关键字大写、缩进清晰即使逻辑有小瑕疵阅卷人看到整洁的答案也会手下留情。交卷前留五分钟做检查重点看几个地方有没有漏写GROUP BY的列、JOIN条件有没有写、NULL值有没有处理、分页的偏移量算对没有。这几个点是我统计下来最容易丢分的地方每次检查都能捞回几分。心得平时练习时养成“写完就自查”的习惯把上面这几个检查项做成固定流程。考试时时间紧靠临时想很容易漏形成肌肉记忆才靠谱。5.4 从笔试到实战哪些知识点真正影响工作说句实在话笔试题里有些偏门知识点工作中确实用不上比如某些冷门函数的返回值细节。但有几类知识是实打实影响日常开发的索引原理决定了你建索引时会不会建错、事务隔离级别决定了你写并发逻辑时会不会出数据问题、执行计划解读能力决定了你排查慢查询的效率。我的建议是备考时把精力重点放在这三块其他语法细节混个眼熟即可。另外笔试里练出来的“读题仔细”习惯在工作中同样值钱。需求文档里的一句话可能就藏着类似“去重”“排除空值”“按什么排序”这样的关键条件读漏了就是线上 bug。从这个角度看刷笔试题不只是为了过面试也是在训练一种严谨的思维方式。
MySQL 笔试题练习及答案一每年招聘季总有一批人在数据库笔试环节栽跟头。不是不会写 SQL而是题目里埋的坑太隐蔽——索引失效、隐式类型转换、聚合函数与 NULL 的纠缠、事务隔离级别的边界情况这些在真实业务里可能被 ORM 框架挡住的问题到了笔试卷面上全暴露出来。我这些年带过不少新人也帮朋友做过模拟面试发现一个规律MySQL 笔试题考的不是你会不会用数据库而是你对底层行为的预判能力。这篇内容就是围绕这个核心展开的把常见的笔试题型拆开揉碎讲清楚每道题背后的原理、出题人的意图、以及实际工作中对应的场景。不管你是刚学完 SQL 基础语法的新手还是工作两三年想跳槽的老手都能从里面找到对自己有用的东西——新手可以当作系统复习的路线图老手可以拿来查漏补缺看看自己是不是也有那些“以为懂了其实没懂”的知识盲区。1. 笔试题型全景与出题逻辑拆解1.1 为什么笔试题总爱考这些“偏门”知识点很多人做完笔试题会有一种感觉平时写业务代码根本用不到这些啊。这话对了一半。业务开发中确实很少手写复杂的多表关联也很少直接操作索引提示但笔试题考的是你对数据库行为的理解深度。出题人心里很清楚一个候选人如果连COUNT(*)和COUNT(column)的区别都说不清楚那他在写分页查询时就很可能踩到性能坑如果不知道NULL在比较运算中的特殊行为那写出来的WHERE条件就可能悄悄漏掉数据。我观察下来MySQL 笔试题的考点分布大致是这样的SQL 语法与查询逻辑占四成左右索引与执行计划占两成半事务与锁占两成剩下的是存储引擎、字符集、权限管理等杂项。这个分布和实际工作中遇到问题的频率基本吻合——查询写不对是日常索引没建好是性能瓶颈的根源事务理解不到位就是数据一致性的定时炸弹。1.2 从题型反推出题人的考察意图拿到一道笔试题别急着写答案先想一个问题出题人为什么这么问。比如一道经典的题目“以下哪个 SQL 语句能查出表中第二高的薪水”看起来是考ORDER BY和LIMIT实际上出题人想确认的是你有没有考虑重复值的情况、有没有考虑表中数据不足两条的情况、以及你知不知道LIMIT的偏移量写法。这三个点分别对应了DISTINCT的使用、IFNULL的处理、以及LIMIT offset, count的语法细节。再比如题目给出一张表结构和几条数据问某个查询的结果是什么。这种题表面考的是 SQL 执行结果深层考的是你对执行顺序的理解——FROM先于WHEREWHERE先于GROUP BYGROUP BY先于HAVINGSELECT里的别名在WHERE中不能用但在ORDER BY中可以用。这些顺序搞不清楚做题就只能靠猜。1.3 备考策略从“会写”到“写对且写快”备考 MySQL 笔试我的建议是分三步走。第一步把基础语法过一遍重点是JOIN的各种变体、子查询的写法、聚合函数的行为。第二步专门练“读题”能力拿到题目先圈出关键词——有没有“去重”、有没有“为空”、有没有“排序后取第几”。第三步限时模拟因为笔试是有时间压力的很多错误不是不会而是想太快导致遗漏条件。这里有个很实用的技巧做完每道题后自己给自己出变体。比如原题是“查第二高”你就想“如果改成查第三高呢”“如果表里只有一条数据呢”“如果有多个相同的最高值呢”。这种自我追问能帮你把知识点串成网而不是孤立地记答案。2. 查询类笔试题的核心陷阱与破解方法2.1 聚合函数与 NULL 的纠缠COUNT 的三种写法差异先看一道高频题表employees中有id、name、department三个字段其中department允许为NULL。问SELECT COUNT(*), COUNT(department), COUNT(1) FROM employees的结果分别是什么。这道题的答案是COUNT(*)统计所有行数COUNT(department)只统计department不为NULL的行数COUNT(1)和COUNT(*)结果相同。很多人知道结论但说不清原因。底层逻辑是这样的COUNT(*)和COUNT(1)走的是“统计行数”的路径优化器会选最小的索引来扫描而COUNT(column)需要逐行判断该列是否为NULL非NULL才计数。所以如果department上有索引且NULL值很少COUNT(department)可能反而更快因为它扫的索引更窄。实际工作中这个知识点直接对应一个场景统计某个字段的“有效填写率”。如果你写COUNT(department) / COUNT(*)得到的就是非空占比。但如果你误写成COUNT(IFNULL(department, 0))那就全算成有效了数据就失真了。注意SUM()、AVG()、MAX()、MIN()这些聚合函数同样会忽略NULL。AVG(column)的分母是非NULL的行数不是总行数。这一点在算平均分、平均薪资时特别容易出错。2.2 子查询与 JOIN 的等价改写什么时候该用哪个笔试题里经常出现这样的要求“查出每个部门薪资最高的员工信息”。标准解法有两种一种是关联子查询一种是JOIN加子查询。先看关联子查询的写法SELECT e.* FROM employees e WHERE e.salary ( SELECT MAX(salary) FROM employees WHERE department e.department );这个写法逻辑清晰但有个隐患如果同一个部门有两个人薪资相同且都是最高两条都会查出来。如果题目要求“每个部门只取一条”那就得加GROUP BY或者用窗口函数。再看JOIN的写法SELECT e.* FROM employees e INNER JOIN ( SELECT department, MAX(salary) AS max_salary FROM employees GROUP BY department ) t ON e.department t.department AND e.salary t.max_salary;两种写法在结果上等价但执行效率可能不同。关联子查询在外层表数据量大时每一行都要执行一次子查询虽然优化器可能会做物化优化但不如JOIN写法稳定。实际开发中我更倾向于JOIN写法因为执行计划更可控而且方便后续加过滤条件。2.3 LIMIT 分页的经典坑偏移量大了怎么办“查出第 10001 到 10100 条记录”这种题考的是LIMIT的偏移量写法LIMIT 10000, 100。但出题人往往还会追问一句这样写有什么性能问题答案是LIMIT 10000, 100会先扫描前 10000 条记录然后丢弃只返回后面的 100 条。偏移量越大扫描的行数越多性能越差。优化思路有两种。第一种是用覆盖索引加子查询SELECT * FROM employees WHERE id (SELECT id FROM employees ORDER BY id LIMIT 10000, 1) ORDER BY id LIMIT 100;这里的前提是id是主键且有索引子查询只扫索引不扫全表拿到起始id后再用主键范围查询取数据。第二种是记录上一页的最大id下一页从id last_id开始查这就是所谓的“游标分页”。第二种方案在无限滚动场景下是标配但缺点是没法跳页。提示笔试答题时如果只写LIMIT 10000, 100可能拿不到满分最好把优化思路也写上哪怕只是提一句“大偏移量建议用延迟关联或游标分页”。2.4 多表关联中的笛卡尔积陷阱一道典型的坑题表 A 有 3 条记录表 B 有 4 条记录问SELECT * FROM A, B返回多少条。答案是 12 条笛卡尔积。如果题目再加一个条件“A 和 B 通过某个字段关联但关联字段有重复值”那结果可能既不是 3 也不是 4而是大于等于 3 的某个数。这类题考的是你对关联键唯一性的敏感度。实际工作中笛卡尔积是慢查询的头号嫌疑犯。我排查过的慢 SQL 里至少三成是因为漏写了关联条件或者关联条件写错导致的行数爆炸。笔试题里遇到多表关联养成一个习惯先确认关联字段在两张表里是不是唯一的如果不是想清楚重复值会不会导致结果翻倍。3. 索引与执行计划类题目深度解析3.1 最左前缀原则为什么你的索引没生效这是索引类笔试题的必考内容。给一个联合索引idx_abc(a, b, c)问以下哪些查询能用上索引WHERE a 1、WHERE b 2、WHERE a 1 AND c 3、WHERE a 1 AND b 2 AND c 3。答案是第一个和第四个能用第二个完全用不上第三个只能用上a这一列。原理在于 B 树索引的排序方式联合索引先按a排序a相同再按b排序b相同再按c排序。所以查询条件必须从最左边的列开始连续匹配中间断了就只能用到断点之前的列。WHERE a 1 AND c 3跳过了b所以c用不上索引只能靠a过滤后再回表逐行判断c。但这里有个容易混淆的点WHERE a 1 AND c 3虽然c用不上索引查找但如果查询的列都在索引里覆盖索引优化器可能选择全索引扫描而不是回表。所以严格来说不是“完全用不上”而是“用不上索引的快速定位能力”。笔试答题时如果遇到判断题要看选项的具体措辞。3.2 隐式类型转换字符串字段传数字的后果看这道题表users中phone字段是VARCHAR(20)类型并且建了索引。执行SELECT * FROM users WHERE phone 13800138000问索引是否生效。答案是不生效因为等号右边是数字类型MySQL 会把字符串列转成数字再比较转换发生在列上索引就失效了。这个坑在实际开发中极其常见。前端传参有时候是字符串有时候是数字后端如果不做类型校验直接拼进 SQL就可能触发隐式转换。更隐蔽的是这种查询不会报错结果也“看起来对”但性能可能差几十倍。我见过一个线上接口QPS 一高就超时最后定位到就是手机号查询没加引号。反过来如果字段是INT类型查询条件传了字符串123MySQL 会把字符串转成数字转换发生在常量侧索引仍然生效。所以规则可以总结为转换发生在列上就失效发生在常量上就没事。3.3 EXPLAIN 关键字段解读type 和 Extra 怎么看笔试题有时会给一段EXPLAIN的输出让你判断查询性能好坏。重点看两个字段type和Extra。type的优劣顺序大致是system const eq_ref ref range index ALL。看到ALL就是全表扫描基本可以判定需要优化看到index是全索引扫描比全表好一点但也不理想ref和range是常见的好状态。Extra字段里Using index表示覆盖索引不需要回表这是好现象Using where表示在存储引擎层过滤后还需要在 Server 层再过滤Using filesort表示需要额外排序如果数据量大就是性能瓶颈Using temporary表示用了临时表常见于GROUP BY和DISTINCT操作。有个细节很多人忽略Using filesort不一定真的用磁盘文件排序如果排序数据量小会在内存里完成。但笔试答题时看到这个词就应该警觉说明排序没有利用索引的有序性。3.4 索引失效的六种典型场景速查除了隐式类型转换还有几种常见的索引失效场景我整理成表格方便对照记忆场景示例失效原因对索引列做运算WHERE id 1 10列参与了计算无法用索引定位对索引列用函数WHERE DATE(create_time) 2024-01-01函数作用在列上索引值被改变前导模糊匹配WHERE name LIKE %张无法确定前缀只能全扫OR 连接非索引列WHERE a 1 OR b 2b 无索引优化器可能放弃索引走全表使用 NOT IN / !WHERE status ! 1否定条件通常无法有效利用索引联合索引跳过最左列索引(a, b)查询WHERE b 2违反最左前缀原则这张表建议直接背下来笔试选择题里出现频率极高。实际开发中写WHERE条件时也可以拿它当检查清单过一遍。4. 事务、锁与存储引擎类题目实战4.1 事务隔离级别与脏读幻读的对应关系笔试题里关于事务的经典问法“在 RC读已提交隔离级别下以下哪种现象不会出现”选项里通常有脏读、不可重复读、幻读。答案是脏读不会出现不可重复读和幻读都可能出现。四个隔离级别的行为对照如下隔离级别脏读不可重复读幻读读未提交可能可能可能读已提交不可能可能可能可重复读不可能不可能可能InnoDB 下基本避免串行化不可能不可能不可能这里有个容易扣分的细节MySQL 的 InnoDB 引擎在可重复读级别下通过间隙锁Gap Lock在很大程度上避免了幻读所以严格说“幻读”在 RR 级别下也不是必然出现。但笔试标准答案通常还是按理论表格来答题时如果遇到判断题要看题目有没有特别说明“InnoDB 引擎”。4.2 行锁与表锁的触发条件“以下哪个操作会加表锁”这类题考的是锁的粒度判断。InnoDB 默认是行锁但以下情况会升级为表锁或者锁住更多行WHERE条件没有走索引时行锁会退化为表锁使用LOCK TABLES语句显式加表锁执行ALTER TABLE等 DDL 操作时。另外SELECT ... FOR UPDATE在没有索引的情况下也会锁全表。实际工作中这个知识点关系到并发性能。我遇到过一个问题两个事务同时更新同一张表的不同行按理说行锁不冲突但实际却互相等待。排查后发现WHERE条件用的字段没有索引行锁退化成了表锁。加索引后问题消失。所以笔试里看到“行锁变表锁”的选项优先考虑索引缺失这个原因。4.3 InnoDB 与 MyISAM 的核心差异对比存储引擎的对比题几乎是必考。核心差异集中在几个维度事务支持InnoDB 支持MyISAM 不支持、锁粒度InnoDB 行锁MyISAM 表锁、外键InnoDB 支持MyISAM 不支持、崩溃恢复InnoDB 有 redo log 支持MyISAM 没有、全文索引早期 MyISAM 支持而 InnoDB 不支持MySQL 5.6 之后 InnoDB 也支持了。笔试答题时如果问“如何选择”标准答案是需要事务和并发写入选 InnoDB纯读场景且对事务无要求可以考虑 MyISAM但实际生产中基本默认 InnoDB。4.4 MVCC 机制简析为什么可重复读能生效MVCC多版本并发控制是 InnoDB 实现可重复读的核心机制。每行记录有两个隐藏字段DB_TRX_ID最后修改该行的事务 ID和DB_ROLL_PTR指向 undo log 的回滚指针。读取数据时InnoDB 根据当前事务的 Read View 判断哪个版本可见。Read View 里记录了活跃事务 ID 列表如果某行的事务 ID 在活跃列表里说明该版本是未提交的就顺着回滚指针找上一个版本。笔试题里可能问“可重复读级别下事务 A 先查询一次事务 B 修改并提交事务 A 再查询结果是否变化”答案是不变因为事务 A 的 Read View 在第一次查询时就确定了后续查询复用同一个 Read View。这个机制保证了同一事务内多次读取结果一致。但要注意如果是当前读SELECT ... FOR UPDATE读的是最新版本不受 Read View 限制。5. 常见易错点与考场实战技巧5.1 那些年我们踩过的 SQL 语法坑笔试里有些错误不是逻辑问题纯粹是语法细节没记牢。比如GROUP BY之后SELECT的列必须是分组列或者聚合函数这在ONLY_FULL_GROUP_BY模式下会直接报错比如HAVING和WHERE的区别WHERE在分组前过滤HAVING在分组后过滤HAVING里可以用聚合函数而WHERE不行再比如UNION和UNION ALL的区别前者去重后者不去重性能上UNION ALL更快。还有一个高频坑ORDER BY后面跟数字表示按第几列排序而不是按常量值排序。ORDER BY 1是按第一列排不是按数字 1 排。这个语法在笔试里经常用来迷惑人。5.2 时间与字符串函数的返回值陷阱日期函数是笔试题的常客。NOW()返回当前日期时间CURDATE()只返回日期DATE_FORMAT()用于格式化。坑点在于WHERE create_time 2024-01-01这种写法如果create_time是DATETIME类型实际上比较的是2024-01-01 00:00:00当天的其他时间数据查不出来。正确写法是WHERE create_time 2024-01-01 AND create_time 2024-01-02或者用DATE(create_time) 2024-01-01但后者会导致索引失效。字符串函数里CONCAT()遇到NULL返回NULL这个行为经常被忽略。CONCAT(a, NULL, b)的结果是NULL而不是ab。如果要做空值兼容得用CONCAT_WS()或者IFNULL()包一层。5.3 笔试答题节奏与检查清单最后分享一个考场上的实操建议。拿到卷子先扫一遍把题目分成三类一眼有思路的、需要想一下的、完全没头绪的。先做第一类保证基础分拿稳再做第二类控制好时间第三类留到最后能写多少写多少。SQL 手写题要注意格式关键字大写、缩进清晰即使逻辑有小瑕疵阅卷人看到整洁的答案也会手下留情。交卷前留五分钟做检查重点看几个地方有没有漏写GROUP BY的列、JOIN条件有没有写、NULL值有没有处理、分页的偏移量算对没有。这几个点是我统计下来最容易丢分的地方每次检查都能捞回几分。心得平时练习时养成“写完就自查”的习惯把上面这几个检查项做成固定流程。考试时时间紧靠临时想很容易漏形成肌肉记忆才靠谱。5.4 从笔试到实战哪些知识点真正影响工作说句实在话笔试题里有些偏门知识点工作中确实用不上比如某些冷门函数的返回值细节。但有几类知识是实打实影响日常开发的索引原理决定了你建索引时会不会建错、事务隔离级别决定了你写并发逻辑时会不会出数据问题、执行计划解读能力决定了你排查慢查询的效率。我的建议是备考时把精力重点放在这三块其他语法细节混个眼熟即可。另外笔试里练出来的“读题仔细”习惯在工作中同样值钱。需求文档里的一句话可能就藏着类似“去重”“排除空值”“按什么排序”这样的关键条件读漏了就是线上 bug。从这个角度看刷笔试题不只是为了过面试也是在训练一种严谨的思维方式。
