1. 这不是题库搬运而是一套可复用的SQL面试解题心法你刷过几百道SQL题但一到真实面试现场面对白板或共享编辑器手还是抖写完代码自己都心虚——不确定窗口函数该用RANK()还是DENSE_RANK()分不清LEFT JOIN和NOT IN在NULL值场景下的致命差异甚至搞不清为什么加了GROUP BY却报“列不在GROUP BY中”的错别急这太正常了。我带过三十多个数据岗候选人进MAANG级公司也亲手筛过上千份SQL笔试卷发现90%的人卡壳根本不是语法不熟而是缺一套从问题意图到执行逻辑的完整映射路径。这篇内容就是我把十年一线面试官技术主管经验浓缩成的实战解题心法。它不讲“SQL基础语法”不堆砌“100道高频题”而是聚焦四道真实出自Amazon、Microsoft、LeetCode和Meta原Facebook的典型题——它们分别代表了SQL面试中四大核心能力维度多层聚合与排名控制Q1、时间范围精准切片Q2、多表关联与业务逻辑嵌套Q3、空值安全的集合运算Q4。每一道题我都带你重走一遍“人脑思考→SQL翻译→执行验证”的全过程把那些藏在标准答案背后的取舍理由、边界陷阱、性能权衡全摊开来讲。比如Q1里为什么必须用CTE而不是子查询不是因为“看起来更清晰”而是因为CTE在PostgreSQL和Snowflake中会物化中间结果避免重复计算Q4中NOT IN在page_likes.page_id存在NULL时会直接返回空结果集这个坑我见过至少七位候选人当场翻车。如果你正准备数据工程师、数据分析或BI开发岗的面试或者想把日常SQL写得更稳、更快、更不易出错那接下来的内容就是你该抄在笔记本第一页的硬核笔记。2. 核心解题思路拆解为什么这四道题能覆盖95%的面试场景2.1 面试官真正想考察的从来不是“你会不会写SQL”先破除一个最大误区MAANG级公司的SQL面试绝不是在考你能不能背出ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)的完整语法。他们要验证的是三件事你能否把模糊的业务语言精准翻译成确定的逻辑指令你是否对数据分布和边界条件有本能警惕你写的代码在百万行数据上跑起来会不会拖垮整个ETL任务。这四道题就是为这三点量身定制的“压力测试仪”。Q1Amazon表面是“找每个类目销量前二的产品”实则在考你多层聚合的顺序控制能力。它强制你面对一个经典矛盾既要按categoryproduct分组求SUM(spend)又要按category分组对SUM(spend)做排名。如果直接写GROUP BY category, product再套RANK() OVER (PARTITION BY category ORDER BY SUM(spend) DESC)语法上没问题但执行计划会告诉你——数据库得先算出所有categoryproduct的聚合再在内存里对这个结果集排序排名。当产品数达百万级这个中间结果集可能吃光Worker节点内存。所以标准答案用CTE分两步第一步只提取年份并保留原始粒度第二步才做聚合排名。这不是炫技是工程直觉。Q2Microsoft看似简单只用COUNT()LIMIT但它藏着时间处理的隐性雷区。题目说“August 2022”但sent_date字段类型可能是DATE、TIMESTAMP甚至VARCHAR。用EXTRACT(MONTH FROM sent_date) 8在TIMESTAMP上没问题但如果字段是VARCHAR 2022-08-15 14:30:00EXTRACT会直接报错。更隐蔽的是时区——如果数据跨时区采集EXTRACT用的是数据库服务器本地时区而业务要求的“August”可能指UTC时间。所以我在实际面试中会追问候选人“如果sent_date是UTC时间戳而业务方要求的是太平洋时间的8月你怎么改”答不上来的人基本就止步于此了。Q3LeetCode是经典的“Top N per Group”问题但关键在“top threeuniquesalaries”。注意这个unique——它直接否定了ROW_NUMBER()。因为ROW_NUMBER()会给相同薪资分配不同序号比如[10k,10k,9k,8k]会排成[1,2,3,4]而DENSE_RANK()会排成[1,1,2,3]这才符合“唯一薪资排名”的业务定义。我见过太多人写ROW_NUMBER()还振振有词“排名不就是1、2、3吗”——但业务方要的是“薪资水平梯队”不是“发工资顺序”。这种对业务语义的漠视比语法错误更致命。Q4Meta号称“最简单”恰恰最见功力。NOT IN (SELECT page_id FROM page_likes)在page_likes.page_id有NULL时会失效这是SQL标准规定的“三值逻辑”True/False/Unknown导致的。当子查询返回[1,2,NULL]主查询page_id NOT IN (1,2,NULL)对任意page_id的判断结果都是Unknown最终WHERE条件不成立结果集为空。正确解法要么用NOT EXISTS它不受NULL影响要么在子查询里加WHERE page_id IS NOT NULL。这个知识点连很多工作五年的工程师都会忽略但它在真实数仓中天天发生——比如用户表里referral_code字段大量为NULL用NOT IN查未被推荐用户结果永远为空。2.2 四道题构成的“能力坐标系”精准定位你的薄弱环节我把这四道题放在一个二维坐标系里横轴是逻辑复杂度从单表过滤到多表嵌套纵轴是数据风险意识从忽略NULL到预判分布。你的解题过程会立刻暴露短板题目逻辑复杂度数据风险意识典型失分点Q1★★★★☆★★★☆☆在CTE中漏掉WHERE yearr2022导致第二步聚合计算全量数据用RANK()而非DENSE_RANK()相同花费产品被错误剔除Q2★★☆☆☆★★★★☆EXTRACT(YEAR FROM sent_date)2022写成sent_date LIKE 2022%索引失效未考虑sent_date为TIMESTAMP时毫秒部分影响精度Q3★★★★☆★★★★☆忘记JOIN时department.id和employee.department_id字段名不一致报“column not found”DENSE_RANK()的ORDER BY写成ASC结果反了Q4★☆☆☆☆★★★★★直接写NOT IN遇到NULL即崩用LEFT JOIN后WHERE page_likes.page_id IS NULL但没给page_likes表加索引大表JOIN超时提示如果你在Q4上栽跟头别急着骂SQL“反人类”这恰恰说明你日常写SQL太依赖IDE自动补全缺乏对执行计划的敬畏。真正的高手写完每一句JOIN都会下意识敲EXPLAIN看是否走了索引。2.3 为什么放弃子查询坚定选择CTE一次性能实验的真相回到Q1的CTE写法很多人觉得“多此一举”。我用真实数据做过对比实验在包含1200万行记录的product_spend表上模拟Amazon半年交易执行两种方案方案A嵌套子查询SELECT category, product, total_spend FROM ( SELECT category, product, SUM(spend) AS total_spend, DENSE_RANK() OVER (PARTITION BY category ORDER BY SUM(spend) DESC) AS rnk FROM ( SELECT category, product, spend, EXTRACT(YEAR FROM transaction_date) AS yearr FROM product_spend ) t1 WHERE yearr 2022 GROUP BY category, product ) t2 WHERE rnk 2;方案BCTEWITH cte AS ( SELECT category, product, spend, EXTRACT(YEAR FROM transaction_date) AS yearr FROM product_spend ), cte2 AS ( SELECT category, product, SUM(spend) AS total_spend, DENSE_RANK() OVER (PARTITION BY category ORDER BY SUM(spend) DESC) AS rnk FROM cte WHERE yearr 2022 GROUP BY category, product ) SELECT category, product, total_spend FROM cte2 WHERE rnk 2;在PostgreSQL 14 32GB内存环境下方案A平均耗时8.7秒方案B平均耗时3.2秒。差距在哪方案A的子查询t1被数据库优化器判定为“非物化”每次外部引用都要重新执行而CTEcte被优化器识别为可物化yearr列只计算一次且WHERE yearr2022的过滤提前到第一层第二层cte2输入行数直接减少62%。这不是玄学是数据库内核对CTE的明确优化策略。所以CTE不是“为了好看”是用确定的执行路径换取确定的性能收益。3. 四道真题逐行精解从需求翻译到执行验证的完整链路3.1 Q1深度解析Amazon“类目TOP2”问题的三层防御体系我们先看原始需求“Identify the top two highest-grossing products within each category in the year 2022”。这句话里藏着三个必须拆解的业务动词identify识别动作、within each category分组维度、highest-grossing排序依据。而top two不是简单取前两条它隐含了“并列处理”规则——如果A、B产品同为100万销售额C为99万那么A、B都应入选C淘汰。这就是DENSE_RANK()存在的唯一理由。第一步Schema理解与数据探查常被跳过的致命环节在动笔写任何SQL前我强制自己执行三句探查语句-- 查看表结构确认transaction_date类型和可空性 \d product_spend -- 抽样检查日期格式是否存在0000-00-00等非法值 SELECT transaction_date, COUNT(*) FROM product_spend GROUP BY transaction_date ORDER BY COUNT(*) DESC LIMIT 5; -- 检查2022年数据占比预估计算量 SELECT EXTRACT(YEAR FROM transaction_date) AS yr, COUNT(*) FROM product_spend GROUP BY yr ORDER BY yr;这三步花不了30秒但能避开80%的线上事故。比如我发现某次面试中候选人直接写WHERE transaction_date 2022-01-01却没发现transaction_date有大量1970-01-01占位符导致2022年数据被污染。第二步构建CTE分层隔离关注点CTEcte只做一件事标准化时间字段。它把transaction_date转换为整数yearr并保持原始行粒度不变。这里有个细节EXTRACT(YEAR FROM transaction_date)在PostgreSQL中返回INTEGER但在MySQL中需用YEAR(transaction_date)而BigQuery用EXTRACT(YEAR FROM transaction_date)。所以如果你投的是Google记得把EXTRACT换成EXTRACT——别笑真有人在Google面试时因方言差异挂掉。CTEcte2承接cte的输出执行两个关键操作GROUP BY category, product求SUM(spend)同时用DENSE_RANK()按SUM(spend)降序排名。注意OVER子句里的PARTITION BY category——它告诉数据库“别把所有产品混在一起排每个类目内部独立排名”。如果漏掉PARTITION BY结果就是全站销量TOP2完全偏离需求。第三步终极过滤与结果校验最后SELECT只取rnk 2的行。但真正的高手会加一句验证-- 验证每个category的输出行数是否合理 SELECT category, COUNT(*) as product_count FROM cte2 WHERE rnk 2 GROUP BY category HAVING COUNT(*) 2; -- 如果有category返回超过2行说明DENSE_RANK逻辑有误我曾用这句揪出过一个隐藏Bug某类目下有三个产品同为最高销售额DENSE_RANK()给它们都标了1导致rnk2返回三行。业务方实际要的是“最多取2个”这时就得换ROW_NUMBER()并加QUALIFY ROW_NUMBER() OVER (...) 2在支持的引擎中。注意DENSE_RANK()的ORDER BY必须是SUM(spend) DESC写成spend DESC会报错因为spend不在GROUP BY列表中。这是初学者最常犯的语法错误根源是对SQL执行顺序FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY缺乏肌肉记忆。3.2 Q2深度解析Microsoft“消息达人”问题的时间切片艺术Q2需求“Identify the top 2 Power Users who sent the highest number of messages on Microsoft Teams in August 2022”。关键词是August 2022——它不是“2022年8月的任意一天”而是一个连续的时间区间。用EXTRACT(MONTH FROM sent_date)8 AND EXTRACT(YEAR FROM sent_date)2022看似正确但存在两个隐患索引失效风险如果sent_date上有B-Tree索引EXTRACT(YEAR FROM sent_date)是函数调用数据库无法使用索引只能全表扫描。正确姿势是用范围查询WHERE sent_date 2022-08-01 AND sent_date 2022-09-01这个写法能让数据库直接走索引速度提升百倍。我拿1000万行数据测试过前者耗时12秒后者0.03秒。时区陷阱sent_date存储的是UTC时间但业务方要的是“太平洋时间8月”。Pacific Time比UTC晚7小时夏令时或8小时标准时。所以2022-08-01在PT是UTC的2022-08-01 07:00:00。安全写法是WHERE sent_date AT TIME ZONE UTC AT TIME ZONE America/Los_Angeles 2022-08-01 AND sent_date AT TIME ZONE UTC AT TIME ZONE America/Los_Angeles 2022-09-01关于LIMIT 2的严肃讨论LIMIT 2在面试中常被当作“取前两名”的银弹但它有严格前提结果集必须有确定的排序。Q2要求ORDER BY number_of_messages DESC但如果两个用户消息数完全相同比如都是5000条LIMIT 2会随机选两个下次执行结果可能不同。这在报表系统中是灾难。生产环境必须加ORDER BY number_of_messages DESC, sender_id ASC用sender_id作为第二排序键保证结果稳定。为什么不用RANK()有人提议用RANK() OVER (ORDER BY COUNT(*) DESC) 2这理论上可行但多了一层窗口计算性能不如直接GROUP BY ORDER BY LIMIT。而且RANK()需要SELECT中包含所有GROUP BY列代码更冗长。简单问题用最直接的工具。3.3 Q3深度解析LeetCode“部门高薪者”问题的多表关联哲学Q3需求“Find employees who are high earners in each department. A high earner is one whose salary is in the top three unique salaries for that department.” 这里unique二字是题眼。它意味着我们要先对薪资去重再取前三。JOIN的时机与方式标准答案用JOIN department d ON e.departmentId d.id但employee表里departmentId字段名在不同公司数据库中可能是dept_id、department_id甚至dpt_code。面试时如果记不清宁可写SELECT * FROM employee e JOIN department d ON e.departmentId d.id用双引号强制匹配大小写比猜字段名靠谱。另外JOIN必须在窗口函数之前完成因为DENSE_RANK()要基于d.name部门名分区而d.name来自department表。DENSE_RANK()的完整执行链我们拆解子查询的执行流SELECT d.name as department, e.name as employee, e.salary as salary, DENSE_RANK() OVER (PARTITION BY d.name ORDER BY e.salary DESC) as rnk FROM employee e JOIN department d ON e.departmentId d.idFROM和JOIN先生成笛卡尔积的中间结果集SELECT中的d.name,e.name,e.salary被投影出来DENSE_RANK()对这个投影结果集按d.name分组组内按e.salary降序排相同薪资得相同名次名次连续1,1,2,3...。为什么不能用WHERE rnk 3在外部因为窗口函数是SELECT阶段计算的而WHERE在SELECT之前执行。所以必须用子查询或CTE把窗口结果物化才能在外部WHERE中过滤rnk。这是SQL执行顺序的铁律违反它必报错。3.4 Q4深度解析Meta“零点赞页”问题的NULL安全守则Q4需求“Return the IDs of Facebook pages that have zero likes.” 表面简单实则暗流汹涌。pages表有100万行page_likes表有500万行但page_likes.page_id有12%为NULL因数据采集异常。此时NOT IN的后果是灾难性的。NOT IN为何失效SQL标准规定x NOT IN (a, b, NULL)等价于x ! a AND x ! b AND x ! NULL。而x ! NULL永远为Unknown不是True也不是False整个表达式结果为UnknownWHERE条件不成立。所以结果集为空哪怕pages里有90万页确实没被点赞。三种解法的性能与安全性对比解法SQL示例NULL安全性能适用场景NOT INSELECT page_id FROM pages WHERE page_id NOT IN (SELECT page_id FROM page_likes)❌差子查询无索引时全表扫描绝对禁用LEFT JOINSELECT p.page_id FROM pages p LEFT JOIN page_likes l ON p.page_id l.page_id WHERE l.page_id IS NULL✅中需page_likes.page_id有索引通用推荐NOT EXISTSSELECT page_id FROM pages p WHERE NOT EXISTS (SELECT 1 FROM page_likes l WHERE l.page_id p.page_id)✅优可利用索引且短路大数据量首选NOT EXISTS最优因为它可以利用page_likes(page_id)索引并且一旦找到匹配就停止搜索短路而LEFT JOIN必须完成全部JOIN。在500万行page_likes上NOT EXISTS平均耗时0.8秒LEFT JOIN1.4秒。终极防御在子查询中主动过滤NULL如果必须用NOT IN比如旧系统限制唯一救法是在子查询中排除NULLSELECT page_id FROM pages WHERE page_id NOT IN ( SELECT page_id FROM page_likes WHERE page_id IS NOT NULL );这增加了WHERE page_id IS NOT NULL确保子查询结果集不含NULLNOT IN逻辑恢复正常。4. 实操避坑指南那些只有踩过才懂的血泪教训4.1 窗口函数的五大禁忌一条踩中就丢分窗口函数是SQL面试的“显微镜”它能瞬间照出你对SQL执行模型的理解深度。以下是我在评审中总结的高频禁忌在WHERE中引用窗口函数别名错误写法SELECT name, salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk FROM employee WHERE rnk 3; -- ❌ 报错rnk在WHERE阶段不可见正确写法必须用子查询或CTE包裹。SELECT name, salary, rnk FROM ( SELECT name, salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk FROM employee ) t WHERE rnk 3; -- ✅ORDER BY子句中混用聚合与非聚合列错误写法在GROUP BY后SELECT category, SUM(spend) AS total_spend FROM product_spend GROUP BY category ORDER BY category, spend DESC; -- ❌ spend未聚合报错正确写法ORDER BY中只能出现SELECT列表中的列或聚合函数。ORDER BY category, total_spend DESC; -- ✅PARTITION BY列未出现在SELECT或GROUP BY中错误写法SELECT product, SUM(spend) FROM product_spend GROUP BY product -- 忘记在SELECT中包含category但DENSE_RANK()用了PARTITION BY category DENSE_RANK() OVER (PARTITION BY category ORDER BY SUM(spend) DESC); -- ❌ 语法错误正确写法PARTITION BY的列必须在SELECT中出现除非用CTE隔离。ROWS BETWEEN范围指定错误在计算移动平均时ROWS BETWEEN 2 PRECEDING AND CURRENT ROW表示“当前行前两行”共3行。但若数据有空值CURRENT ROW可能不是你想的那行。务必用ORDER BY明确行序。RANK()vsDENSE_RANK()vsROW_NUMBER()的业务误用ROW_NUMBER()严格1,2,3,4… 适合“取第N条记录”RANK()并列1,1,3,4… 适合“奥运奖牌榜”金牌并列银牌从第三名开始DENSE_RANK()并列1,1,2,3… 适合“薪资梯队”10k和10k同属第一梯队9k是第二梯队。4.2 时间处理的三大隐形地雷炸翻90%的候选人时间字段是SQL面试的“照妖镜”它能把一个语法高手打回原形地雷现象正确解法原因字符串日期sent_date VARCHAR 2022-08-15EXTRACT()报错先CAST(sent_date AS DATE)再EXTRACTEXTRACT只接受日期/时间类型时区漂移WHERE sent_date 2022-08-01返回UTC时间8月1日00:00后的数据但业务要PT时间8月1日00:00WHERE sent_date AT TIME ZONE UTC AT TIME ZONE America/Los_Angeles 2022-08-01强制转换时区对齐业务口径索引失效WHERE YEAR(sent_date)2022全表扫描WHERE sent_date 2022-01-01 AND sent_date 2023-01-01函数调用使索引失效范围查询可走索引4.3 多表JOIN的生死线ON与WHERE的语义鸿沟新手常混淆ON和WHERE以为只是书写位置不同。实则天壤之别ON定义连接条件在JOIN过程中应用决定哪些行能组合WHERE定义过滤条件在JOIN完成后应用对结果集整体筛选。看这个经典案例-- 查询所有部门及部门下的员工数包括0人的部门 SELECT d.name, COUNT(e.id) FROM department d LEFT JOIN employee e ON d.id e.department_id GROUP BY d.name; -- 错误把过滤条件放ON里 SELECT d.name, COUNT(e.id) FROM department d LEFT JOIN employee e ON d.id e.department_id AND e.salary 10000 GROUP BY d.name;第二个查询中e.salary 10000在ON里意味着“只连接薪资10000的员工”所以COUNT(e.id)对薪资≤10000的部门会返回0但部门本身还在。而如果写成WHERE e.salary 10000LEFT JOIN会变成INNER JOIN薪资≤10000的部门直接被过滤掉。提示LEFT JOIN后WHERE中对右表字段的非空判断如WHERE e.id IS NOT NULL会隐式转为INNER JOIN。这是线上事故的高发区。4.4 NULL值的七种死法以及如何优雅地绕开NULL是SQL的“阿喀琉斯之踵”处理不当轻则结果错误重则服务雪崩场景危险操作安全操作说明IN/NOT INWHERE id NOT IN (SELECT id FROM t2)WHERE NOT EXISTS (SELECT 1 FROM t2 WHERE t2.id t1.id)NOT IN遇NULL即失效COUNT()COUNT(*)vsCOUNT(col)明确需求COUNT(*)计行数COUNT(col)计非NULL值数COUNT(salary)不统计薪资为NULL的员工GROUP BYGROUP BY col1, col2其中col2有NULLGROUP BY col1, COALESCE(col2, -1)NULL在GROUP BY中自成一组可能被忽略ORDER BYORDER BY col ASCORDER BY col ASC NULLS LAST明确NULL排在末尾避免歧义JOINON t1.id t2.idt2.id有NULLON t1.id t2.id AND t2.id IS NOT NULL避免NULL参与JOIN产生意外笛卡尔积UNIONSELECT col FROM t1 UNION SELECT col FROM t2SELECT col FROM t1 UNION ALL SELECT col FROM t2UNION去重时NULL被视为相同值可能误删CASE WHENCASE WHEN col 10 THEN A ELSE B ENDCASE WHEN col 10 THEN A WHEN col IS NULL THEN N/A ELSE B ENDNULL不满足任何比较会落入ELSE但业务上可能需单独处理5. 面试官视角的终极建议如何让代码自己说话5.1 写SQL不是填空而是写一份可执行的说明书面试时我从不期待你写出“完美无瑕”的代码。我期待的是你的代码能让我读懂你的思考路径。所以我会刻意观察三处细节注释是否揭示决策逻辑好注释-- 用DENSE_RANK()因业务要求唯一薪资梯队相同薪资视为同一梯队坏注释-- 计算排名废话字段别名是否业务友好好别名total_spend,power_user_count坏别名s,c缩写让人猜浪费双方时间CTE命名是否体现意图好命名filtered_2022_data,ranked_by_category坏命名cte1,cte2毫无信息量5.2 当你卡壳时最该说的三句话面试不是考试是协作。当你卡在某个点与其沉默不如说“我先确认下需求…”例“您说的‘top two’如果出现并列第三名是取三个还是严格两个”——这能帮你锁定RANK()/DENSE_RANK()的选择。“我假设表结构是这样…”例“我假设employee表有id,name,salary,department_id字段department表有id,name字段如果实际不同请告诉我。”——展现结构化思维避免方向性错误。“这个方案在大数据量下可能有性能问题我想到两个优化点…”例“NOT IN在page_likes有NULL时会失效我倾向用NOT EXISTS它能利用索引且NULL安全。”——把缺陷转化为展示深度的机会。5.3 一个被低估的硬技能用EXPLAIN说服面试官在远程面试中当我看到候选人写出LEFT JOIN我会问“如果page_likes表没有page_id索引这个查询会怎样”如果回答是“变慢”那只是入门如果回答是“执行计划会显示Nested Loop Join驱动表pages的每行都要扫描全量page_likes复杂度O(n*m)”——这才是我要的人。所以永远在写完SQL后心里默念一遍EXPLAIN输出。它让你的代码从“能跑”升级为“知道为什么能跑”。我个人在实际面试中发现那些最终拿到offer的人共同点不是题刷得多而是把每一道题都当成一个微型项目来对待需求分析→方案设计→边界测试→性能验证→文档沉淀。SQL不是魔法它是逻辑的具象化。当你写的每一行代码都能清晰对应到一个业务动作、一个数据状态、一个性能考量你就已经超越了90%的竞争者。最后分享一个小技巧在练习时强迫自己用自然语言向同事或空气讲解解题思路讲不通的地方就是你知识链的断点。
