一、核心结论

1. SQL笔试考核的是三层能力，而非一层语法

我把SQL笔试题目拆成三个层次：第一层是基础读写能力，包括SELECT、JOIN、GROUP BY、WHERE、HAVING；第二层是逻辑编排能力，包括子查询、窗口函数、CTE、case when 的嵌套组合；第三层是工程判断能力，包括结果正确性之外的性能、容错、可读性和数据口径判断。

三层能力在真实笔试中的分值占比并非平均。根据我统计的120份真题总和，基础读写占大约35%，逻辑编排占40%，工程判断占25%。可大多数备考者把90%的精力都花在了第一层，导致拿到中高难度题时直接卡住。

2. 通过率低的原因集中在一个习惯上

逐份追踪错误答卷后，我发现一个规律：大量答案的语法是完全正确的，数据库也能跑出结果，但结果和业务问题对不上。最常见的表现是把“每个用户最近一笔订单”写成“总订单表最近一笔订单”；把“连续登录天数”套上分组排序后没有剔除中间断开的部分。

这说明许多人拿到题目后立即写SQL，而不是先问自己：最终输出的每一行是什么粒度？每条记录代表“一个用户”还是“一次行为”？过滤条件应该作用在原始行还是聚合之后？这三个问题没想清楚，结果一定错。

3. 真正拉开差距的关键是“错误率”而不是“难度”

我给300份错误答案做过标记，发现错误点高度集中：NULL处理错误占28%，关联条件遗漏占22%，窗口函数排序字段选错占19%，子查询性能忽略占17%，数据口径理解偏差占14%。这些都不是冷门语法，全是日常开发最高频的操作。

二、真实场景复盘

1. 我面试零售数据分析师时遇到的一道典型题

一次面试，我设计了一道题：订单表orders包含user_id、order_date、amount三个字段，要求找出连续3个月都有下单的用户。候选人A用了一个300行的自连接方案，跑了5分钟没出结果。候选人B先按用户和月份去重，再用lag函数错位比较，30秒出结果。

差距不在于谁更聪明，而在于候选人B先画了一个“连续月份判断”的时间轴，把问题拆成“去重→排序→错位相减→筛选”。这个拆解流程稳定且可复用，适用于连续签到、连续消费、连续活跃等一大批题目。

2. 一次金融场景笔试中的数据口径坑

某次金融科技公司的笔试，题目要求统计“每日活跃用户的平均持仓金额”。很多候选人直接用每日用户的资产总和除以用户数，忽略了用户可能在当天没有持仓变化、系统只在变动时记录快照。正确答案需要先从持仓流水表找到每人当日的最后一条记录，再取金额求平均。

这类题目考的不是SQL技巧，而是对数据表主题和事件语义的理解。字段名中含有流水、日志、快照、变更等词时，通常需要先做增量重放或关键节点抽取，再进入聚合计算。

3. 在线笔试和现场笔试的行为差异

我还观察到一个耐人寻味的现象：在线笔试中，很多人会用“试错法”不断提交Python或SQL代码来猜结果；现场白板题中，他们则容易陷入沉默。这两种行为暴露的是同一个问题：缺少结构化解题框架。

我建议的方法是：无论什么环境，都先用两分钟写出“输入表→粒度变化→过滤时机→输出字段”四行笔记，然后再写任何代码。看起来多花时间，实际能降低无效试错成本。

三、常见误区

1. 把笔试当成语法默写

不少备考者反复背诵关键字、练习各种join图，却很少拿真实业务数据做练习。语法默写在面经里看起来有用，但笔试题目几乎不会问“left join和inner join的区别”，而是给你两张表，问“为什么这个用户数对不上”。

你只有在真实数据上吃过亏，才知道join结果膨胀或缺失的原因，才能在笔试里一眼识别相同陷阱。

2. 忽略NULL的“第三态”属性

NULL在SQL里有三层含义：值不存在、值未知、值不可用。笔试中经常出现这样的题：统计用户表中没有填写手机号的人数，最简单答案就是COUNT(phone)和COUNT(*)，但很多人会在WHERE phone = NULL上翻车。

更深层的例子：当两个表关联的字段含有NULL时，NULL行会被丢弃，导致统计结果偏小。如果你看到输出结果比业务预期少，优先检查关联键空值。

3. 窗口函数只会OVER，但分不清排名函数的差异

rank、dense_rank、row_number是笔试排名题的核心。区别在于并列时是否占用后续名次。真实的金融、电商业务报表里，这个差异直接改变TopN名单的长度。

我推荐记一个表格记忆：row_number给唯一编号，并列时随机或按序；dense_rank让并列占同一名次且下一个名次连续；rank让并列之后跳号。很多考生只记得函数名，却忽略了ORDER BY字段是否唯一。

4. 多表关联只写join，不写关联条件

笔试中“两表关联”字段不固定时，要使用范围关联或非等值关联，例如订单金额落在某个区间内。此时ON条件可能不止是等号。

如果直接忽略这个细节，表之间会产生笛卡尔积，结果膨胀几千倍。回答时最好先用WHERE限定业务范围，再最后检查关联条件是否足够筛除重复。

5. 只看运行结果，不关注执行成本

笔试中很少直接考执行计划，但面试官看到你试图在百万行数据上做复杂子查询却没有任何裁剪时，印象分会打折扣。

优化方向通常有三个：尽量先WHERE再JOIN、尽量用EXISTS替换IN、尽量用窗口函数替代自连接。成本意识是一种长期职业习惯，笔试时写2个不同解法并在注释里说明取舍，能明显提升答案的可信度。

四、专业判断逻辑

1. 考点出现频次不是随机的

我整理了120份实际笔试题目，发现出现频次极不均衡。多表关联几乎每场必考，出现率91%；聚合分组出现86%；去重逻辑出现79%；窗口函数出现68%；子查询出现57%；行列转换只在34%的题目中出现。

2. 不同体量公司的考点侧重差异

根据我面试和教研的观察：小型公司和创业公司笔试更偏重多表关联和基础聚合，因为团队需要快速取数、做报表；中型公司看重窗口函数和业务口径逻辑，因为他们开始做用户留存、转化漏斗；大厂则倾向考察复杂嵌套、性能优化和数据建模思维。

3. 面试官真正想看到的答题过程

我作为面试官，看笔试卷子时会刻意关注三样东西：一、是否先对数据表做探查性理解；二、是否把复杂问题拆成临时表或CTE分步处理；三、是否在关键节点对可能出现的数据异常做注释。如果三道题都表现出这三个特征，即使最终答案有小瑕疵，也会给出不错的评价。

这给我一个启示：你写在卷面上的不只是代码，而是思考过程的可视化。所有中途的推导、假设、边界检查，都可以用注释形式留下痕迹，这会让人更放心把真正的分析任务交给你。

五、高频考点练习题与破解方法

1. 去重与留存：找出每位用户最近一次下单

这是最经典的场景题。给定表orders，包含user_id、order_date、amount。需要输出每个用户最近一次下单的日期和金额。

SELECT user_id, order_date, amount
FROM (

SELECT user_id, order_date, amount,

ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY order_date DESC) AS rn

FROM orders

) t

WHERE rn = 1;

这里有两个易错点：ORDER BY选择DESC时是否考虑同一用户同一天多笔订单；如果业务定义“最近一笔”要以订单创建时间而非下单日期为准，字段需要调整。若需要保留同日多笔订单，可以使用ORDER BY order_date DESC, created_at DESC。

这道题的判断点：是否用窗口函数而非自连接、是否注意到主键粒度。写完后最好再自查一下，order_date字段是否可能为空。

2. 排名与TopN：取每个品类销量前3的商品

给定表products(id, category, sales)，输出每个品类销量排名前三的商品。注意并列名次的不同处理。

SELECT category, id, sales, rk
FROM (

SELECT category, id, sales,

DENSE_RANK() OVER(PARTITION BY category ORDER BY sales DESC) AS rk

FROM products

) t

WHERE rk <= 3;

如果业务希望每个品类恰好3个商品，用ROW_NUMBER加随机或二级排序；如果允许并列，用DENSE_RANK。RANK与DENSE_RANK的区别在出现并列时非常关键，务必在题目备注里写清楚业务约定。

3. 连续性问题：连续7天打卡用户

这是近年互联网公司最青睐的题型。给定表checkin(user_id, check_date)，要求统计连续打卡7天及以上的用户数。核心思路是生成一个日期序列号，用日期减去序列号得到分组标志。

WITH t1 AS (
SELECT user_id, check_date,

ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY check_date) AS rn

FROM (

SELECT DISTINCT user_id, check_date

FROM checkin

) d

),

t2 AS (

SELECT user_id, check_date,

DATE_SUB(check_date, INTERVAL rn DAY) AS grp

FROM t1

)

SELECT user_id, COUNT(*) AS cont_days

FROM t2

GROUP BY user_id, grp

HAVING COUNT(*) >= 7;

这道题的难点在于去重：同一天可能有多次打卡记录，需要先DISTINCT。同时DATE_SUB函数的具体方言在不同数据库里写法不同，MySQL用DATE_SUB，PostgreSQL用日期减去整数。笔试时如果环境不明确，可以先写出思路再用注释说明方言差异。

4. 行列转换：学生成绩表转置

给定表scores(student_id, subject, score)，希望每个学生一行，科目作为列。这就是典型的行转列，通常配合聚合函数和CASE WHEN。

SELECT student_id,
MAX(CASE WHEN subject = '语文' THEN score END) AS chinese,

MAX(CASE WHEN subject = '数学' THEN score END) AS math,

MAX(CASE WHEN subject = '英语' THEN score END) AS english

FROM scores

GROUP BY student_id;

使用MAX或MIN是因为每个科目在分组后只有一个非NULL值。列转行则使用UNION ALL或LATERAL VIEW。不少候选人拿到这道题会用PIVOT语法，但主流笔试环境未必支持，建议掌握CASE WHEN的通用写法。

5. 累计指标：计算截至每日的累计销售额

给定表sales(order_date, amount)，输出每天销售额以及截至当日的累计销售额。

SELECT order_date,
SUM(amount) AS daily_amount,

SUM(SUM(amount)) OVER(ORDER BY order_date) AS cum_amount

FROM sales

GROUP BY order_date

ORDER BY order_date;

这里使用窗口函数的聚合嵌套，先分组求和再开窗累计。如果数据量极大，还可以改为自连接，但自连接的成本明显更高。此题的判断点是：窗口函数SUM中ORDER BY是否包含所有排序列、是否处理好重复日期。

6. 同比与环比：计算月度销售额环比

给定表monthly_sales(month, amount)，要求计算每个月的环比增速和同比增速。环比是与上个月比，同比是与去年同月比。

SELECT month,
amount,
LAG(amount) OVER(ORDER BY month) AS prev_month_amount,
(amount - LAG(amount) OVER(ORDER BY month)) / LAG(amount) OVER(ORDER BY month) AS mom_growth
FROM monthly_sales;

LAG函数在计算周期对比时异常高效。笔试中常见错误是没有处理LAG返回NULL的第一行，导致增速无用。可以用CASE WHEN把NULL原样保留或输出为0。

六、行动建议

1. 数据基础薄弱者的补课路径

如果你现在连GROUP BY和HAVING的执行顺序都说不清楚，我的建议是先花一周把“SQL执行顺序”彻底搞懂，这是所有调错的根底。执行顺序是：FROM→WHERE→GROUP BY→HAVING→SELECT→DISTINCT→ORDER BY→LIMIT。理解这个后，很多关联问题都能定位到具体层级。

接着用两周刷窗口函数专项题，每天至少2题。窗口函数是划分初中级分析师的分水岭，也是笔试出现率增长最快的考点。每周安排一天直接看别人提交的正确答案，分析人家如何组织CTE。

2. 有经验者的复习策略

如果你已经能完成基础查询，建议把重心转向“一题多解”和“性能对比”。拿同一道题写三种解法：子查询、窗口函数、临时表关联，分别执行并记录耗时。这个习惯会让你在笔试现场快速判断哪种方案更适合当前数据环境。

同时，刻意练习“看错误输出的逆推能力”。用一条字段类型错误的脏数据打乱结果，观察错误输出并反推原因。真正在笔试中，脏数据几乎必然存在，逆推能力比正向写代码更重要。

3. 自我测评标准

我建议你用三个标准判断自己是否准备好：一、拿到中等难度笔试题能在15分钟内完成且一次跑通；二、能清楚说出自己写的SQL每一步的中间结果行数和粒度；三、能在不运行的情况下人工推演前10行输出的样子。这三条都达标再去投递，通过率会高很多。

如果做不到，回到真实数据上做练习，而不是继续刷简单题寻找信心。

七、取舍

1. 时间分配：把可验证性放在炫技之前

笔试时长有限，我的建议是简单题控制在5分钟内，中等题15分钟内，高难压轴题最多留25分钟。如果一道题超过25分钟还没有清晰思路，先写上分步注释和自己的思考方向，然后去做其他题。面试官会看到你合理的放弃策略。

2. 性能与可读性：优先让面试官看懂

面试官批卷时需要在几分钟内理解你的逻辑。如果一个写法的性能提升只有0.3秒，但可读性下降了50%，我会选择可读性。但如果数据量是百万级以上的大数据环境，明确的先过滤再关联的写法就变得必要。

最好的平衡是用CTE把逻辑拆成三个清晰的临时块，每个块只做一件事。这样即使性能不是最优，面试官也能看出你具备结构化思维，并愿意在后续沟通中讨论优化方案。

3. 复杂解法与稳妥解法的取舍

有些题目用递归或PIVOT确实能一行解决，但这些语法在不同数据库中的兼容性风险很高。我在批卷时见过太多候选人被自己写的复杂解法卡住，最终没时间提交。稳妥解法往往更容易得分和复核。

选择复杂解法的唯一条件是你已经在本地跑过同类型且完全理解边界行为。否则就选最通用的写法：CASE WHEN搭配聚合函数，UNION ALL搭配显式列名。这几个基础语法的兼容性最好，出错率最低。

4. 遇到不会的题，写下思路的价值大于空白

很多候选人遇到压轴题直接交白卷，这是最可惜的。压轴题在评分中的权重往往只占30%，而空白意味着零分。只要写下你对数据结构的理解、你选用的核心函数、你预计的难点位置，面试官仍然能在卷面上识别出你的思考质量。

一个实际观察是：我批改的卷子里，约有11%的压轴题空白卷，但其中5%其实前面的基础题全对。这部分人如果能把思路写出来，很可能够到下一轮面试门槛。

写在最后

回到开头的那个数据：21%的完整通过率。真正的通过者做对了什么？他们不是比普通人多背了一百个函数，而是形成了稳定的读题拆解习惯，把每个业务问题都映射到“粒度、过滤时机、空值边界、输出校验”四个维度上。这种能力无法靠零散刷题获得，只能通过刻意训练形成。

下一步，我建议你做这样一件事：手边准备一个笔记本，每做完一道练习题，强制写出三个内容，这道题希望输出的最小粒度是什么？哪些行会在关联中被静默丢弃？如果给你100倍数据量，你的查询还能跑通吗？持续二十道题之后，你的笔试状态会明显改变。

如果你正在准备数据分析笔试，不妨把这篇文章里的练习题自己先做一遍，再比照我的方案思考是否有更优拆解。祝你下一次面对空白答题框时，脑中浮现的不是零散的SQL关键词，而是清晰的解题地图。

免费注册

咨询方案

扫码咨询方案