最近不少准备数据分析、商业分析岗位面试的朋友问我SQL到底要复习到什么程度面试官到底会怎么考。说实话我面过不少候选人也在面试中被问过很多次SQL这个专题确实是数据岗笔试和面试的重头戏。很多同学SQL基础语法都会但一到现场写题就卡壳问题往往不是不会写而是不知道面试官想听什么、想看什么。这篇文章我就以我实际面试和整理面试题的经验把数据分析/商业分析岗位SQL面试的高频考点、题型思路和解法逻辑梳理一遍希望能帮你在准备阶段少走弯路。这篇文章适合正在准备数据分析师、商业分析师、经营分析岗位面试的同学也适合那些SQL基础不错但不确定面试考察重点的人。我会从面试官考察意图、高频题型、手写SQL的答题技巧、慢SQL优化这几个维度展开基本覆盖我在真实面试中见过的大部分SQL题目类型。1. 面试官考SQL的真实意图不是考语法是考数据思维很多人以为SQL面试就是在考语法记忆背几个函数就能过关这个理解从一开始就跑偏了。作为面试官我看候选人写SQL真正观察的是三件事第一你拿到一个业务问题能不能把它翻译成正确的取数逻辑第二你的SQL写得是否严谨有没有考虑重复、空值、边界这些细节第三你的答案是否具备可扩展性和可维护性而不是只会拼一条能跑出结果的语句。1.1 三层能力模型取数、逻辑、业务理解我习惯把SQL面试考察的能力拆成三层。第一层是取数能力也就是你能否用SQL从数据库里准确拿到想要的数据。这一层考察的是基础语法SELECT、JOIN、WHERE、GROUP BY、窗口函数这些用得是否熟练。大部分候选人这一层都能过关但准确性往往不够比如漏掉去重、没有处理NULL、关联条件写错导致数据膨胀这些都是我在面试中经常看到的问题。第二层是逻辑能力考察的是面对一个相对复杂的业务问题时能否用清晰的逻辑拆解问题。这里典型的就是留存率、复购率、连续登录这类问题。这类题考察的语法本身并不难难的是分析链路——你要先想清楚分母是谁、分子是谁、按什么维度计算、时间范围怎么选定然后才能动手写SQL。逻辑能力不是靠背题能补上来的需要平时有针对性的练习。第三层是业务理解能力也就是你能不能把SQL的结果和业务指标对应起来。比如面试官问“这个店铺的月复购率是多少”好的答案会先界定清楚“什么叫复购”——是一次购买后30天内再次购买还是自然月内的多次购买不同的口径会得到完全不同的数值。业务理解能力是我区分优秀候选人和普通候选人的关键它无法靠突击培训获得只能靠日常分析工作中的积累。1.2 盘点面试中出镜率最高的几类SQL题根据我自己的面试经历和帮朋友模拟面试的经验数据分析/商业分析岗位的SQL题目大致可以分成以下几类按出现频率从高到低排列。第一梯队是窗口函数相关题目包括分组TopN、累计求和、同比环比、排名去重等。现在的数据岗面试窗口函数几乎是必考的它天然适合处理“分组内排序”“跨行计算”这类分析场景。第二梯队是业务指标计算题最常见的就是留存率、复购率、连续登录天数、活跃用户数、GMV计算等。这类题目的特点是看似简单但考察细节很多比如时间口径、用户去重、跨月问题。第三梯队是基础查询与聚合题包括去重、空值处理、多表关联、CASE WHEN条件统计等。这类题通常出现在笔试前几题属于热身题但正因为简单反而容易因为粗心丢分。第四梯队是SQL优化题包括慢SQL原因分析、索引使用、查询重写等。这类题在数据分析岗面试中出现频率不如开发岗高但在商业分析、高级数据岗位中越来越常见主要考察候选人是否有性能意识。了解这些题型分布之后准备方向就比较清晰了。基础语法要熟练窗口函数必须掌握业务指标题要多练思路性能优化也要有基本认识。接下来我按这几个方向把每一类题型的重点和典型例题展开讲。2. 基础关去重、空值与聚合统计的高频陷阱基础题虽然难度不高但恰恰是失分重灾区。我见过很多候选人写复杂窗口函数头头是道结果在简单的去重题上栽跟头。这一节我把基础查询里最容易出问题的几个点拆开讲。2.1 DISTINCT不是万能的去重查询的真正应用边界面试题里“查询去重后的用户数”“统计有购买记录的用户ID”这类题目考察的就是DISTINCT和GROUP BY的使用。DISTINCT用于对查询结果进行去重它作用于SELECT后面的所有列。比如下面这条语句去重的是(uid, date)这个组合而不是单独的uidSELECT DISTINCT uid, visit_date FROM user_visits;如果面试官要的是“每天有多少个独立用户访问”正确的写法是GROUP BY COUNT(DISTINCT)SELECT visit_date, COUNT(DISTINCT uid) AS uv FROM user_visits GROUP BY visit_date;这里有一个经常被忽略的细节COUNT(DISTINCT)的性能通常比先子查询去重再COUNT要差因为它在聚合阶段对每一组都执行去重操作。但如果只是取数分析、数据量不大用COUNT(DISTINCT)更简洁。我在面试中更青睐候选人在这个点上主动提到性能权衡这代表他不是只会背语法。另一个常见场景是“某张明细表中每个用户最新的一条记录”。很多候选人第一反应是写GROUP BY取MAX(时间)但这样取不到这条记录的其他字段。这时候正确的解法是用窗口函数ROW_NUMBER()这个问题在后面窗口函数部分会详细展开。我要强调的一点是面试中遇到“去重”不要条件反射只写DISTINCT要先想清楚去重的粒度是什么、需不需要保留其他字段。2.2 NULL值处理比你想的更“反常识”NULL值的处理是SQL面试中特别容易踩坑的点因为很多候选人没有真正理解NULL的三值逻辑。在SQL中NULL代表“未知”它不是空字符串也不是零更不等于任何值。因此任何与NULL直接比较的表达式结果都是”未知”UNKNOWN在WHERE条件中未知会被当作FALSE处理。下面这个例子就很典型-- 期望找出所有没有填写手机号的用户 SELECT * FROM users WHERE phone NULL; -- 错误查询结果恒为空 -- 正确写法 SELECT * FROM users WHERE phone IS NULL;这个看似简单的点在面试中却高频出现。还有一种变形考法统计某个字段的非空数量。比如一张订单表要统计有优惠券id的订单数SELECT COUNT(*) AS total_orders, COUNT(coupon_id) AS coupon_orders FROM orders;COUNT(字段)会自动忽略NULL而COUNT(*)会统计所有行。所以count(coupon_id)天然就是“优惠券id不为空的订单数”。很多候选人不知道这个特性还在用WHERE coupon_id IS NOT NULL再子查询绕了一圈还没人家写得简练。除了比较和计数NULL还会影响聚合结果。SUM、AVG、MAX、MIN这些聚合函数都会忽略NULL值但有一个例外是COUNT(*)它统计的是行数。如果一张表的某个字段大量为NULLAVG这个字段时会得到偏高或偏低的值这一点在做商业分析时格外重要——分析前一定要先确认数据的缺失情况。2.3 聚合函数和GROUP BY的配合细节聚合是SQL面试的另一个基础考点。面试官经常通过一道题考察你是否理解GROUP BY的执行逻辑先分组再聚合最后过滤。常见的错误是把WHERE和HAVING搞混。WHERE是在分组前过滤行HAVING是在分组后过滤组。下面这道“查询下单次数大于5次的用户”题正确写法是SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id HAVING COUNT(*) 5;这里不能用WHERE COUNT() 5因为WHERE在分组之前执行此时COUNT()还不存在。还有一类题目考察的是“分组后取多条记录”比如按品类分组找出每个品类下销量最高的商品。不少候选人会用GROUP BY MAX(销量)结果只能得到每个品类的最高销量拿不到对应商品名称。要同时拿到商品信息正确的做法是窗口函数或者先关联子查询后面我会专门讲窗口函数解法。基础题目虽然分值不高但它是后续所有复杂查询的基石。面试时基础题写得好不好直接影响面试官对你整体水平的判断。我建议你把DISTINCT、NULL处理、GROUP BY和HAVING的区别这几块吃透这些都是在面试中反复出现但又特别容易出错的点。3. 窗口函数专题从“会写”到“写得漂亮”的分水岭窗口函数是近几年数据分析岗面试的绝对高频考点。原因很简单——日常业务分析中排名、累计、对比、同环比这些需求靠普通GROUP BY写起来很别扭但窗口函数几乎是为此量身定做的。面试官通过窗口函数题目能快速判断候选人有没有真正做过分析类工作而不只是写过CRUD。3.1 ROW_NUMBER、RANK、DENSE_RANK的区别与选择这三个函数长得很像都是对分组内的行进行编号、排名但规则不同也正因如此成了面试中的经典送命题。函数相同值处理排名是否连续典型场景ROW_NUMBER()相同值分配不同序号序号连续取分组内第1条记录RANK()相同值并列同一个名次名次有断档1,1,3并列后跳过名次DENSE_RANK()相同值并列同一个名次名次连续1,1,2需要紧凑排名的场景举个例子有一张销售表按销售额对销售员排名SELECT salesperson, sales_amount, ROW_NUMBER() OVER (ORDER BY sales_amount DESC) AS row_num, RANK() OVER (ORDER BY sales_amount DESC) AS rank, DENSE_RANK() OVER (ORDER BY sales_amount DESC) AS dense_rank FROM sales;如果销售额分别为100、90、90、80那么ROW_NUMBER得到1、2、3、4RANK得到1、2、2、4DENSE_RANK得到1、2、2、3。面试官问“取每个部门薪资最高的员工”这类题目默认用ROW_NUMBER()最稳妥因为一个人不会同时占据两个最高位次如果你用RANK()可能会返回两个人并列第一的情况反而和题目本意不符。这里有一个我实际面试中发现的常见错误很多候选人分不清窗口函数中的ORDER BY和普通查询的ORDER BY。窗口函数中的ORDER BY只决定窗口内的排序规则不改变最终结果集的行序。如果你要最终的查询结果按某个字段排序还是需要在最外层加ORDER BY。这个细节在写分页、拼接行号的时候特别容易踩坑。3.2 累计、环比、TopN三个必练的窗口函数经典场景窗口函数在数据分析中最常用的几个场景也是面试题的题源我来逐个过一下。场景一累计求和。比如“统计每个用户每个月的消费金额并计算截至每个月的累计消费金额”这是典型的累加场景用SUM() OVER()解决SELECT user_id, month, monthly_amount, SUM(monthly_amount) OVER (PARTITION BY user_id ORDER BY month) AS cumulative_amount FROM ( SELECT user_id, DATE_FORMAT(create_time, %Y-%m) AS month, SUM(amount) AS monthly_amount FROM orders GROUP BY user_id, DATE_FORMAT(create_time, %Y-%m) ) t;关键点在于ORDER BY month它定义了累加的方向——从最早月份到最晚月份逐行累加PARTITION BY user_id则保证累加是在每个用户内部独立进行的。如果去掉ORDER BY那SUM() OVER()就是分区内所有行的总和区别很大。场景二同环比计算。商业分析岗面试特别喜欢考这个因为它直接和业务报表挂钩。“计算每个月的销售额以及环比增长率”先拿到月度销售额再用LAG()取上个月的销售额SELECT month, sales_amount, sales_amount - LAG(sales_amount) OVER (ORDER BY month) AS month_over_month_growth, (sales_amount - LAG(sales_amount) OVER (ORDER BY month)) / LAG(sales_amount) OVER (ORDER BY month) AS growth_rate FROM monthly_sales;LAG()取的是同一分区内前N行的值默认前1行。这里用LAG而不是自关联写法简洁得多性能也好很多。面试如果延伸到“环比上月增长率”还会考察除零问题——如果上月值为0或者NULL除法会报错或得到NULL这时候需要加NULLIF或者CASE WHEN判断。能主动提到这个细节的候选人通常能给我留下好印象因为这说明他真正写过报表知道实际数据有多脏。场景三分组TopN。这是窗口函数题中出现频率最高的类型。“查询每个品类销量前3的商品”典型的写法是SELECT category_id, product_id, sales_volume FROM ( SELECT category_id, product_id, sales_volume, ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY sales_volume DESC) AS rn FROM product_sales ) t WHERE rn 3;这个题面试官通常会追问如果要并列第3名怎么改答案是换成DENSE_RANK()。如果只要前3条不管并列用ROW_NUMBER()。这些细微差别正是考察候选人对业务口径的理解面试时不要闷头写写完最好主动说明一下你选用的排名函数和理由。窗口函数的学习曲线其实不陡核心就是理解PARTITION BY、ORDER BY和窗口范围三者的组合。建议把排名、累计、LAG/LEAD、FIRST_VALUE/LAST_VALUE这几个函数都练熟它们是数据岗面试中出现频率最高的窗口函数考点。4. 业务场景题留存率、复购率、连续登录这类题型的完整解法业务场景题是数据分析/商业分析面试的压轴大题也是区分候选人分析能力的关键。这类题目的特点是业务背景复杂、细节陷阱多、解法不止一种面试官更看重你拆解问题的思路而不是最终答案。4.1 用户留存率从明细表到留存矩阵留存率是互联网数据分析岗面试中出现次数最多的业务指标题没有之一。它的典型问法是“计算某日新增用户在次日、7日、30日后的留存率”。这里关键要先明确口径新增用户是指当天首次产生某个行为比如注册、首次访问、首次下单的用户留存用户是指这些新增用户中在目标时间窗口内再次产生行为的用户。留存率的公式是目标日期还在活跃的新增用户数 / 目标日期新增用户数。假设有一张用户登录日志表user_login字段包括user_id、login_date另有一张用户注册表user_register字段包括user_id、reg_date。计算注册用户次日、7日留存率的SQL如下SELECT DATE(reg_date) AS reg_day, COUNT(DISTINCT a.user_id) AS new_users, COUNT(DISTINCT CASE WHEN DATEDIFF(b.login_date, a.reg_date) 1 THEN a.user_id END) AS retained_1d, COUNT(DISTINCT CASE WHEN DATEDIFF(b.login_date, a.reg_date) 7 THEN a.user_id END) AS retained_7d, COUNT(DISTINCT CASE WHEN DATEDIFF(b.login_date, a.reg_date) 1 THEN a.user_id END) / COUNT(DISTINCT a.user_id) AS retention_1d, ... FROM user_register a LEFT JOIN user_login b ON a.user_id b.user_id GROUP BY DATE(reg_date);这个解法里有几个容易踩的坑。LEFT JOIN会产生一对多关系一个注册用户登录了多次就会产生多行所以统计留存用户数时一定要加DISTINCT。DATEDIFF的方向不要写反。更重要的是这个查询只适用于注册和登录在同一时间段内、数据量适中的情况如果数据量很大推荐先用子查询把每个用户在注册后第1天、第7天是否登录提前去重再关联统计性能会好很多。面试时还有变体题比如“计算7日留存漏斗”“新增用户中分别在D1、D3、D7有访问行为的各占多少”。本质上就是留存矩阵逻辑一致稍作扩展即可。回答这类题的关键是先讲清楚口径再动手写SQL。4.2 连续登录N天断档问题的标准解法连续登录问题是另一个经久不衰的面试题。最常见的问法是“找出连续登录7天以上的用户”。这个题目第一次做很容易懵因为连续性的判断在SQL里没有直接的函数。标准解法是“日期减去行号”的技巧。核心思路是如果用户连续登录那么用登录日期减去一个递增的序号得到的日期值应该相同。WITH login_rank AS ( SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM (SELECT DISTINCT user_id, login_date FROM user_login) t ), login_group AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL rn DAY) AS group_date FROM login_rank ) SELECT user_id, MIN(login_date) AS start_date, MAX(login_date) AS end_date, COUNT(*) AS days FROM login_group GROUP BY user_id, group_date HAVING COUNT(*) 7;第一步去重很重要。如果同一天有多次登录不去重就会导致行号不连续影响分组结果。DATE_SUB(login_date, INTERVAL rn DAY)这一步是整个技巧的核心连续登录的日子里login_date每天加1rn也每天加1二者相减保持不变一旦断档差值就会变化。这样就把“连续性”问题转化成了“分组”问题。我在面试中遇到过候选人写出正确SQL、但解释不清楚为什么DATE_SUB要减rn的。面试官追问的时候你不仅要会写还要能把原理讲明白。上面这段逻辑建议自己动手推演一遍理解了之后就很顺手了。这类题还有个常见变体找连续登录天数最多的用户。思路一样在外面套一层ROW_NUMBER或者直接按天数倒序取第一条即可。4.3 复购率与客单价商业分析面试中的延伸考点商业分析岗的面试题通常更贴近收入、订单、用户价值这些指标其中复购率和客单价是高频考点。复购率的经典问法是“计算一个月内复购用户占整体购买用户的比例”。这里的核心难点是口径界定同一用户在同一天内购买多次算不算复购不同的业务定义会有不同答案有的公司“复购”指的是同一用户在不同自然日再次购买有的则只要下单次数大于1就算。面试时先抛出这个问题往往能让面试官觉得你有业务意识。假设定义为“自然月内下单次数大于1的单的用户占比”SQL如下SELECT month, COUNT(DISTINCT CASE WHEN order_cnt 2 THEN user_id END) AS repurchase_users, COUNT(DISTINCT user_id) AS total_buyers, COUNT(DISTINCT CASE WHEN order_cnt 2 THEN user_id END) / COUNT(DISTINCT user_id) AS repurchase_rate FROM ( SELECT user_id, DATE_FORMAT(order_date, %Y-%m) AS month, COUNT(*) AS order_cnt FROM orders GROUP BY user_id, DATE_FORMAT(order_date, %Y-%m) ) t GROUP BY month;客单价类题目也很常见比如“计算每个店铺的客单价”客单价 销售额 / 有效购买人数。这里同样有口径问题一个用户买了多件商品算一个人退款订单是否扣除、凑单订单是否计入都需要和业务对齐。面试官往往故意不说明这些口径看你会不会反问。业务场景题准备的核心方法是建立「指标口径 → SQL拆解 → 细节校验」的思考链路。平时可以拿公司的数据练手把活跃率、留存率、复购率、ARPU这些常用指标都用SQL自己算一遍面试时自然就有底气了。5. SQL性能优化面试中的“隐形加分项”相比纯开发岗数据分析岗对SQL优化的考察深度不会那么重但面试官会通过一到两个简单问题判断候选人是否具备性能意识和排查能力。尤其是现在数据量越来越大“能跑出结果”和“能在合理时间内跑出结果”是两码事。5.1 慢SQL优化的完整排查思路面试中问慢SQL优化最常见的问法是“有一条SQL查询特别慢你从哪些角度排查”。这是一个开放性问题考察的是系统性思考能力而不是背知识点。我在实际工作中总结的排查链路大致是这样先看执行计划确认SQL走了哪些索引、扫描了多少行再看表数据量和查询条件判断是否是索引失效或者SELECT了过多列然后看是否存在N1查询或重复扫描比如在循环里查数据库这在数据分析脚本里经常出现最后看是否需要重写SQL逻辑比如把关联查询改为子查询、把多表关联拆成两次查询、或者把复杂计算放到应用层。面试中我建议候选人按这个顺序回答先通过EXPLAIN查看执行计划再定位主要瓶颈在扫描行数、关联字段还是排序操作然后针对具体瓶颈做优化。如果候选人一上来就说“加索引”我会觉得他缺少排查意识。5.2 索引失效的典型场景与优化示例索引是最常见的优化手段但也是面试里最容易暴露理解偏差的地方。以下几个场景是索引失效的典型情况面试官经常拿出来考。第一对索引列使用函数或计算索引失效。比如WHERE YEAR(create_time) 2025无法使用create_time上的索引应改为范围条件-- 慢对索引列使用函数 SELECT * FROM orders WHERE YEAR(create_time) 2025; -- 优化使用范围条件 SELECT * FROM orders WHERE create_time 2025-01-01 AND create_time 2026-01-01;第二隐式类型转换。如果字段是varchar类型但是查询条件里传了数字MySQL会做隐式转换索引也可能失效。比如WHERE user_phone 13800138000虽然能查到结果但user_phone是字符串建议写成WHERE user_phone 13800138000能走索引。第三LIKE前置通配符。WHERE name LIKE %张因为通配符在开头无法利用索引如果改成WHERE name LIKE 张%就可以利用索引前缀匹配。面试时不用把所有场景都背下来关键是讲清楚索引失效的底层规律。索引本质上是有序的数据结构当你的查询破坏了这棵树的顺序性比如用函数包裹、类型不一致、前导通配符优化器就没办法再利用索引的有序性做快速定位了。你把这个规律讲清楚面试官自然知道你是在真正理解索引而不是背了几条经验口诀。数据分析岗位的SQL优化题通常不会超出上面这些范围。如果你还想额外加分可以主动提一下分区表、分页查询优化、用EXISTS代替IN等常见做法但注意不要停留在名词层面要能说一两个实际使用场景。6. 面试实战经验手写SQL的答题节奏与表达技巧技术能力是基础但面试毕竟是面对面的沟通怎么把脑子里的思路表达出来直接影响面试官对你的评价。我在面试中见过不少基础扎实但表达混乱的候选人非常可惜。这一节聊聊手写SQL题时的答题节奏和表达技巧。6.1 拿到题目后的三步思考法很多人一看到题目就开始狂写写了一半发现理解错了又涂掉重来这在面试中是非常减分的行为。我建议你拿到一道SQL题之后严格执行下面三步思考。第一步先确认业务口径。题目问的是“累计消费金额”那累计的起点是什么从注册开始还是从有消费行为开始题目问的“留存”第N天是从哪天开始算如果有不确定的地方一定要问面试官。别怕提问会显得你能力不行恰恰相反准确提问在面试官看来是业务敏感度的体现。第二步在草稿纸上画出数据到结果的转换流程。不需要画多复杂简单写一下原始表 → 按什么字段分组/去重 → 用什么函数 → 输出的列有哪些。这一步能让你的思路可视化后面写SQL时不易跑偏。第三步根据转换流程选择对应的SQL语法。需要排名就用窗口函数需要跨行计算就用LAG/LEAD需要分组合并就写GROUP BY HAVING。写的过程中不要闷头一路写完写几步就出声解释一下你这一步在做什么这样面试官能实时看到你的思路也能在关键处指出问题避免你走到死胡同。这三步看起来简单但实际面试中能做到的人不多。训练方法也简单多刷题特别是按“先讲口径、再画流程、最后写码”的口径来练。练到形成肌肉记忆面试中就不会慌张了。6.2 现场写SQL最容易翻车的几个细节结合我自己的面试经验和看到的大量候选人表现现场写SQL最容易翻车的细节集中在以下几个方面。第一语法不够细心丢分丢得莫名其妙。关键字拼错、表名字段名写错、括号不匹配、别名不一致这些低级错误在电脑上写代码时有编译器提醒面试现场写在纸上的时候就完全靠细心了。我的建议是写完以后自己心里跑一遍检查SELECT的字段是否都能在FROM的表里找到GROUP BY的字段是否都出现在SELECT的非聚合列中。第二没有处理NULL和去重。很多候选人一看到“统计用户数”就直接COUNT(user_id)完全不管user_id可能有重复。还有些候选人算比率的时候用COUNT(A) / COUNT(B)不考虑除数为0的情况。这些都是实际分析中必须考虑的问题面试题默认数据不太干净就是为了考察你会不会主动加DISTINCT、会不会用CASE WHEN排除异常。第三不会主动解释窗口函数和GROUP BY的结果差异。如果一道题既可以用GROUP BY也可以用窗口函数解但结果含义不同你在写完后如果能主动说明“这里用ROW_NUMBER而不是GROUP BY是因为我们需要保留每个用户的最新记录及其完整字段而不是只取聚合值”面试官对你的印象会明显上升。第四面试过程中别沉默。手写SQL题最怕候选人一声不吭地写完提交哪怕错了面试官也看不到你的思路没法给过程分。哪怕只是说一句“我先把用户和订单关联起来再按日期分组统计”也比完全沉默要好。写在最后的一点建议SQL面试的准备没有捷径但也不需要陷入漫无边际的刷题状态。根据我的经验把基础语法、窗口函数、业务指标题、性能优化这四个方向分别练熟再搭配十道左右的综合模拟题做冲刺就足以覆盖绝大多数数据分析/商业分析岗位的面试要求。我在面试候选人时最看重的是他能不能把一个模糊的业务问题一步步拆解成清晰的取数逻辑并意识到数据质量对结果的影响。这也是你日常工作中真正每天都在用的能力。如果时间有限优先练窗口函数和业务指标题如果还有余力再把SQL优化和表达节奏打磨一下。准备好这些下次面试时遇到SQL题就不用发怵了。