去年秋天帮朋友做模拟面试我随手抛了一道题把每个部门薪资第二高的员工捞出来。他先写了三层嵌套子查询加一个自连接跑了几秒还漏掉了并列的情况面试官当场追问“如果并列的人有三个呢”。换成 MySQL 窗口函数这题就是DENSE_RANK()两行代码的事。窗口函数在 MySQL 8.0 之后已经不算新特性了但它依旧是数据库面试里区分度最高的一块内容——会写GROUP BY的人满地都是能说清楚帧Frame默认行为的人不多。这篇内容我打算按我自己准备面试和带新人的顺序来写先讲清楚它和聚合函数的本质差别再把语法拆成能背下来的结构然后按用途把常见窗口函数分门别类最后拿八道真实出现过的面试题逐条过一遍 SQL 和追问。不管你是刚学完基础查询想补短板还是工作几年后重新准备跳槽都能直接拿来当复习提纲。1. 从“每组取TopN”说起为什么窗口函数成了必考题1.1 一道三层子查询写出来的题暴露了什么先说那道题的具体形态。表结构很简单emp(emp_id, dept_id, name, salary)要求每个部门薪资最高的两名员工。不用窗口函数的写法通常是先按部门分组求出最高薪资再用NOT IN或者比较排除掉最高的取剩下的最大值——也就是所谓的“第二高”。这个思路在只有两三个部门、几百行数据的演示库里跑得动但一旦遇到真实数据就有三个问题同时爆发。第一个问题是并列。如果某个部门有两个人都拿 20000那“第二高”到底算谁NOT IN的写法会把两个人都排除掉最后返回第三名的薪资。第二个问题是扩展到 Top3、Top10 时SQL 的长度会随着 N 线性增长无法参数化。第三个问题是性能自连接本质上是把表跟自己做了笛卡尔积再过滤数据量上去之后索引基本失效。面试官出这道题考的不是你能不能拼出一个能跑的 SQL而是你有没有意识到“分组内排名”这个需求本身应该是数据库提供的能力。窗口函数就是这个能力的正式答案它不是语法糖而是把过去需要多次扫描、多次自连接才能表达的语义压缩成一次扫描加一次排序。1.2 GROUP BY 会塌缩行数窗口函数不会这是理解窗口函数最重要的一句话我建议你把它当成锚点记住GROUP BY是塌缩式的窗口函数是叠加式的。SELECT dept_id, AVG(salary) FROM emp GROUP BY dept_id执行完之后五行员工数据变成了三行部门数据你失去了员工个体的信息。如果这时候你既想看每个部门的平均薪资又想看每个员工自己的薪资和部门平均的对比用GROUP BY就得再关联回原表SQL 变成两段式。窗口函数的行为完全不同每一行输入对应一行输出行数不变只是在每一行后面挂了一个“基于某个窗口算出来的值”。AVG(salary) OVER (PARTITION BY dept_id)会在每个员工行上给出他所属部门的平均薪资。所谓“窗口”指的是当前行能看到的那一组行——可以是整个部门也可以是部门内排在他前面的那些人这个差别由帧来决定后面会专门拆。提示判断该用哪种问自己一句话——我输出的行数应该和输入一样吗一样就用窗口函数要收敛就用 GROUP BY。1.3 面试官问窗口函数其实在考什么我带过几个新人发现很多人背了函数名却答不上追问原因是没搞清楚考察点。按我的经验窗口函数的面试题其实在分层考察三件事。第一层是语义理解你能不能说出RANK()和DENSE_RANK()在并列时的差异这属于八股答不上来基本就凉了。第二层是帧的理解SUM(x) OVER (ORDER BY d)和SUM(x) OVER ()结果差在哪为什么LAST_VALUE会返回当前行这一层筛掉大部分人。第三层是工程判断同样的需求有没有非窗口函数的实现5.7 环境怎么办加了窗口函数之后执行计划变成什么样数据量大了会不会拖垮实例。一个能答完三层的候选人和一个只答出第一层的候选人在面试官眼里是两档人。所以下面的内容我会刻意往二三两层倾斜尤其是帧和性能这两块。2. 把语法拆成三段窗口函数的脑子怎么转2.1 OVER 括号里的三段式结构窗口函数的完整形态可以写成这样函数名(参数) OVER ( PARTITION BY 分组列 ORDER BY 排序列 帧定义 )我习惯把它当成三个可以独立回答的问题来理解。PARTITION BY回答的是“窗口的边界在哪”也就是当前行和哪些行属于同一组ORDER BY回答的是“组内怎么排序”它决定排名的顺序也影响帧的默认范围帧定义回答的是“当前行能看到组内的哪些行”也就是只看到它前面的、还是看整组。最关键的是这三段里只有OVER是必须的括号里可以写一个、两个或者三个都不写。COUNT(*) OVER ()就是整个结果集当窗口什么分区都不分这在算“全表总数占比”的时候特别好用一行都不用额外查。参数部分要单独说一下。ROW_NUMBER()、RANK()、DENSE_RANK()、NTILE(n)这类函数括号里不接字段NTILE接桶数LAG、LEAD可以接三个参数分别是表达式、偏移量、默认值写成LAG(amount, 1, 0)而SUM、AVG、COUNT、MAX、MIN直接沿用聚合函数的写法。记住这个分类写的时候不容易手滑。2.2 逻辑执行顺序为什么 WHERE 里写不了窗口函数MySQL 的逻辑执行顺序大致是FROM→WHERE→GROUP BY→HAVING→ 窗口函数计算 →SELECT列表求值 →DISTINCT→ORDER BY→LIMIT。窗口函数被安排在HAVING之后、SELECT之前意味着两件事。一是它看到的是分组之后的数据所以你可以在OVER里面套聚合函数比如SUM(SUM(amount)) OVER (PARTITION BY dept_id)先按部门汇总再加总这在算“部门销售额占公司总额比例”时很顺手。二是WHERE和HAVING的执行时机都在它之前那时候窗口函数的计算结果还不存在写上去一定会报错。报错信息通常是ERROR 3593 (HY000): You cannot use the window function row_number in this context。正确姿势是把窗口函数的结果放进子查询或 CTE在外层过滤-- 错误写法 SELECT emp_id FROM emp WHERE ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) 1; -- 正确写法 WITH ranked AS ( SELECT emp_id, dept_id, salary, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM emp ) SELECT emp_id, dept_id, salary FROM ranked WHERE rn 1;顺带提一句ORDER BY是排在窗口函数之后的所以你可以用窗口函数的别名排序也可以把窗口函数直接写在ORDER BY子句里这一点和其他很多数据库的表现一致。2.3 WINDOW 子句把重复的窗口定义收拢起来一个真实报表里往往要同时算好几个窗口指标每个OVER都抄一遍PARTITION BY dept_id ORDER BY hire_date代码会又长又容易改漏。MySQL 8.0 支持命名窗口SELECT emp_id, dept_id, salary, ROW_NUMBER() OVER w AS rn, SUM(salary) OVER w AS dept_running, AVG(salary) OVER (w ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS ma3 FROM emp WINDOW w AS (PARTITION BY dept_id ORDER BY salary DESC);命名窗口可以互相继承括号里写(w 新的帧定义)就是在已有定义上覆写帧。除了可读性它还有一个容易被忽略的好处当多个窗口定义完全相同时MySQL 只需要排一次序。我实测过几个并行窗口的查询把重复定义收进WINDOW子句之后执行计划里的排序节点数量确实会减少。分区分组逻辑不一致的时候优化器只能分别排序多出来的每一轮排序都是实打实的开销。3. 按用途分类记函数比背20个名字管用3.1 排名三兄弟ROW_NUMBER、RANK、DENSE_RANK这三兄弟的差异在面试里几乎必考我用一张表说清楚假设薪资序列是10000, 10000, 9000, 8000函数返回值特点ROW_NUMBER()1, 2, 3, 4严格递增并列时按额外规则决定先后RANK()1, 1, 3, 4并列同名次后续名次跳号DENSE_RANK()1, 1, 2, 3并列同名次后续名次不跳号选哪个完全取决于业务语义。取“每个部门薪资最高的一个人”用ROW_NUMBER()因为你不管并列就要一个代表。取“薪资排名前两档的人”用DENSE_RANK()因为你要的是“档位”而不是“个人”。取“并列都算并列后面名次空着”这种考试成绩单式的排名用RANK()。ROW_NUMBER()有个细节必须注意并列的时候它的结果是不确定的具体谁拿 1 谁拿 2 取决于扫描顺序和排序实现。如果业务上要求并列时以入职时间早的优先就得在ORDER BY里补第二个、第三个排序键写成ORDER BY salary DESC, hire_date ASC, emp_id ASC把排序键凑成唯一结果才稳定可复现。我见过线上导出报表每次数字都不一样的事故根因就是排序键不唯一。3.2 前后值函数LAG、LEAD、FIRST_VALUE、LAST_VALUELAG和LEAD是用来做相邻行比较的环比、同比、相邻两单时间差都靠它们。SELECT ym, amt, LAG(amt, 1) OVER (ORDER BY ym) AS prev_1, LAG(amt, 12) OVER (ORDER BY ym) AS prev_12 FROM monthly_sales;细节在于边界行。第一行没有前一行LAG默认返回NULL参与算术运算之后整个结果还是NULL报表上会突然出现空白。要么用第三个参数给个默认值LAG(amt, 1, 0)要么在外层用IFNULL包一层。用 0 要注意语义——把缺失值当 0 会算出 -100% 的环比报表同事多半会来找你。FIRST_VALUE和LAST_VALUE取的是窗口内第一个和最后一个值但它俩的坑不一样。FIRST_VALUE在默认帧下行为符合直觉LAST_VALUE则会让第一次用的人怀疑人生原因放在下一章细说。3.3 聚合函数挂上 OVER 之后语义的变化SUM、AVG、COUNT、MAX、MIN这五个函数一旦挂上OVER行为就从“整组汇总”变成了“窗口内汇总”。窗口范围由帧决定如果帧不写而OVER里带了ORDER BY默认帧是“从分区第一行到当前行”于是SUM自动变成了累计求和。SELECT order_date, amount, SUM(amount) OVER (ORDER BY order_date) AS running_total, COUNT(*) OVER (PARTITION BY user_id) AS user_order_cnt FROM orders;上面第一个是累计第二个是用户维度的总数因为没写ORDER BY整个分区都是窗口。这个“写不写 ORDER BY 会导致语义彻底改变”的特性是窗口函数里最容易被忽略的一点也是很多线上数字对不上的根源。再补一个高级用法聚合函数和DISTINCT组合时MySQL 8.0 支持COUNT(DISTINCT x) OVER (PARTITION BY d)用来算组内去重计数。但要注意它和SUM一起用的时候限制比较多遇到报错就退回两层查询处理。3.4 NTILE、PERCENT_RANK、CUME_DIST 什么时候真用得上NTILE(n)把分区内的行按顺序尽量均匀地切成 n 桶返回桶号。它在业务上最典型的用法是分层抽样和评分分档比如把用户按消费金额分成十档看各档的留存差异。除不尽的时候前面的桶会多一行这一点在验证数据分布时值得注意。PERCENT_RANK()返回(rank - 1) / (行数 - 1)CUME_DIST()返回的是小于等于当前值的行数占比。两者都是相对位置指标做 A/B 测试的分位数切分、算 P95 响应时间挺方便。真正算中位数最直观的还是ROW_NUMBER配COUNT我在第 5 章会给完整写法。说句实在话这三个函数在实际业务代码里出现频率远低于排名和偏移类但面试官喜欢问因为它们能证明你系统读过文档而不是只抄过例子。4. 帧Frame才是面试官真正的分水岭4.1 不带 ORDER BY 和带 ORDER BY默认帧完全不同这是全篇最值得反复读的一段。帧的默认值取决于OVER里有没有ORDER BY没有ORDER BY默认帧是ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING也就是整个分区。有ORDER BY默认帧是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW也就是从分区第一行到当前行的所有同行值。所以SUM(amount) OVER (PARTITION BY user_id)和SUM(amount) OVER (PARTITION BY user_id ORDER BY order_date)是两个完全不同的指标前者是用户总额后者是用户累计消费。差一个ORDER BY报表能差出十倍数字。显式写帧的语法是ROWS BETWEEN 起点 AND 终点起点终点可以是UNBOUNDED PRECEDING、n PRECEDING、CURRENT ROW、n FOLLOWING、UNBOUNDED FOLLOWING。常用组合就那么几个ROWS UNBOUNDED PRECEDING是累计求和的标准写法ROWS BETWEEN 6 PRECEDING AND CURRENT ROW是七日滑动平均ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING是三行平滑。提示只要你的指标涉及“累计”“滑动”“到当前为止”就把帧显式写出来。默认帧虽然能用但它是给不熟悉的人埋的雷写清楚比省几个字符值钱得多。4.2 LAST_VALUE 返回当前行不是 bug新人最常问的一个问题为什么LAST_VALUE(salary) OVER (PARTITION BY dept_id ORDER BY salary)每一行返回的都是它自己的薪资因为带了ORDER BY默认帧的终点是CURRENT ROW窗口的最后一个值就是当前行本身。这个函数在你没显式指定帧的时候行为等于什么都没做。要取分区真正的最后一行必须把帧改成ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWINGSELECT emp_id, dept_id, salary, FIRST_VALUE(salary) OVER (PARTITION BY dept_id ORDER BY salary DESC) AS top_salary, LAST_VALUE(salary) OVER (PARTITION BY dept_id ORDER BY salary DESC ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS bottom_salary FROM emp;这个知识点在面试里几乎百分百会被问到答出“默认帧终点是当前行”就够了能补一句“所以要显式改成 UNBOUNDED FOLLOWING”就是加分项。4.3 RANGE 与 ROWS 在并列数据上的分歧帧的两种模式ROWS按物理行数算RANGE按值算。默认帧用的是RANGE这一点在数据有并列时会造成非常反直觉的结果。假设某个用户一天下了三单SUM(amount) OVER (ORDER BY order_date)用默认的RANGE模式会把同一天的三单一起加进累计值所以这三行的累计结果完全相同。改成ROWS UNBOUNDED PRECEDING三行就是严格按行递增的累计。销售日报这种“一天多单”的场景两种模式算出来的曲线形状完全不一样。我的经验是做累计金额、累计订单数这类指标一律用ROWS因为它语义明确、可复现做“按时间粒度分组汇总”的语义时才考虑RANGE。另外 MySQL 对RANGE支持的是数值和时间类型的差值偏移RANGE BETWEEN INTERVAL 7 DAY PRECEDING AND CURRENT ROW这种写法在某些版本上不一定支持用之前先在你自己的环境里跑一遍。5. 八道高频题的完整解法与追问准备5.1 每部门薪资 Top2 与并列处理SELECT * FROM ( SELECT emp_id, dept_id, name, salary, DENSE_RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rk FROM emp ) t WHERE rk 2;追问一如果并列的人只能取一个怎么办把DENSE_RANK()换成ROW_NUMBER()并在ORDER BY里补hire_date或者emp_id保证唯一。追问二如果要求返回的是“薪资大于部门平均值的第二名”就得在OVER里先用AVG(salary) OVER (PARTITION BY dept_id)算均值再另起一个ROW_NUMBER注意一个 SELECT 里不能嵌套窗口函数得用两层 CTE。5.2 连续登录天数差值分组法的完整推导这题的核心技巧叫“差值分组”连续日期的特点是与行号相减之后结果恒定。WITH d AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) DAY) AS grp FROM (SELECT DISTINCT user_id, login_date FROM login_log) x ) SELECT user_id, MIN(login_date) AS start_date, MAX(login_date) AS end_date, COUNT(*) AS continuous_days FROM d GROUP BY user_id, grp HAVING COUNT(*) 3;推导过程讲清楚很加分假设某用户登录日期是 3-01、3-02、3-03行号分别是 1、2、3相减都得到 2-28说明它们属于同一个连续段。中间的 3-03 和 3-05 断开后后面那段的行号变了减出来的日期也跟着变自然形成新的分组键。两个必须注意的点第一登录表里同一天可能有多条记录内层一定要先DISTINCT否则行号会被重复记录顶偏第二login_date如果是DATETIME类型要先DATE()截断不然同一天的 09:00 和 21:00 会被当成两天。5.3 环比、同比与累计曲线的写法WITH m AS ( SELECT DATE_FORMAT(order_date, %Y-%m) AS ym, SUM(amount) AS amt FROM orders GROUP BY ym ) SELECT ym, amt, LAG(amt, 1) OVER (ORDER BY ym) AS prev_month, ROUND((amt - LAG(amt, 1) OVER (ORDER BY ym)) / NULLIF(LAG(amt, 1) OVER (ORDER BY ym), 0) * 100, 2) AS mom_pct, SUM(amt) OVER (ORDER BY ym) AS ytd_amount FROM m;这里有两个实战经验。一是除法要用NULLIF(分母, 0)兜底否则遇到零销售额的月份直接报错或者返回NULL一片用IFNULL包成 0 又会误导业务最稳妥的是让它显示为NULL加一条备注。二是月份排序不能按字符串排2024-10会排到2024-2前面%Y-%m格式恰好是定长所以能正确排序但如果你用的是%Y-%-m就会出错干脆在 CTE 里额外SELECT DATE_FORMAT(order_date,%Y-%m-01)转成日期类型再排。5.4 去重保留最新、中位数与分组占比去重保留最新一条是生产环境里用得最多的窗口函数场景DELETE FROM user_profile WHERE id IN ( SELECT id FROM ( SELECT id, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC, id DESC) AS rn FROM user_profile ) t WHERE rn 1 );这里有三层嵌套不是故意写得绕而是 MySQL 不允许在DELETE的子查询里直接引用被删的表多包一层派生表把它物化掉才能绕开限制。ORDER BY里加id DESC是为了在updated_at相同时保证结果唯一——如果没有第二排序键每次跑出来的保留记录可能不同。中位数的写法WITH r AS ( SELECT dept_id, salary, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary) AS rn, COUNT(*) OVER (PARTITION BY dept_id) AS cnt FROM emp ) SELECT dept_id, AVG(salary) AS median_salary FROM r WHERE rn IN (FLOOR((cnt 1) / 2), CEIL((cnt 1) / 2)) GROUP BY dept_id;偶数行取中间两个的平均奇数行取正中间那个用一个IN同时覆盖两种情况外层AVG自动完成合并。分组占比的写法更简单SELECT emp_id, dept_id, salary, ROUND(salary / SUM(salary) OVER (PARTITION BY dept_id) * 100, 2) AS pct_in_dept FROM emp;这题适合用来展示“从多个窗口定义里挑一个合适的帧”——占比算的是整组所以OVER里千万不能加ORDER BY加了就变成累计占比了。5.5 被追问“5.7 怎么办”时怎么答问到这一句说明面试官在考察你的知识边界。标准答案是MySQL 5.7 没有窗口函数只能用用户变量模拟。SET rn : 0, dept : NULL; SELECT emp_id, dept_id, salary, rn FROM ( SELECT emp_id, dept_id, salary, IF(dept dept_id, rn : rn 1, rn : 1) AS rn, dept : dept_id AS d FROM emp ORDER BY dept_id, salary DESC ) t WHERE rn 2;紧接着一定要补上风险用户变量的赋值和读取依赖优化器实际执行顺序SQL 里出现WHERE、JOIN、GROUP BY之后执行顺序就不再等于书写顺序结果会变得不可预测。MySQL 8.0 已经把这种用法标记为弃用。所以线上如果还在 5.7正确做法是把逻辑落到应用层做或者先物化到临时表再处理不要在生产查询里赌优化器的行为。6. 上生产前的验证清单执行计划、索引与版本差异6.1 用 EXPLAIN ANALYZE 看窗口函数到底干了什么窗口函数写得对不对是逻辑问题快不快是执行计划问题。MySQL 8.0.18 之后可以用EXPLAIN ANALYZE它会输出实际执行的行数和耗时比传统EXPLAIN更直观。带窗口函数的查询执行计划里通常能看到Window aggregate节点如果OVER里带了ORDER BY前面还会挂一个Sort节点。EXPLAIN ANALYZE SELECT * FROM ( SELECT emp_id, dept_id, salary, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM emp ) t WHERE rn 1;有个性能误区值得专门说外层的WHERE rn 1不会减少窗口函数的计算量。窗口函数在排序完成之后才逐行计算出rn派生表被物化外层过滤发生在最后一步。所以你以为“只要第一行所以很快”实际上还是全表扫加全量排序。真正想减少计算量得先在 CTE 里把数据范围缩小比如加时间条件过滤掉历史数据。6.2 排序代价与索引能不能帮上忙窗口函数最贵的部分永远是排序。当PARTITION BY的列和ORDER BY的列正好能被同一个索引覆盖时优化器有机会利用索引的有序性省掉排序如果分区和排序列分散在不同索引上那就得老老实实建临时表排序。我的经验是给窗口函数建索引时按(PARTITION BY 列, ORDER BY 列)的顺序设计复合索引例如PARTITION BY dept_id ORDER BY salary DESC对应idx(dept_id, salary DESC)就很合适。但要说清楚一点这个优化能不能生效由优化器判断不同小版本的行为也可能不同别把它当成必然还是以EXPLAIN ANALYZE实测为准。另一个容易被忽视的问题是内存。大分区排序会消耗sort_buffer_size和临时表空间超出阈值就会落盘。分区基数特别大的时候比如按用户 ID 分区查上千万用户排序中间结果会非常可观这种场景更适合先在应用层或中间表里把范围收敛下来再算。6.3 窗口函数在 UPDATE、HAVING、DISTINCT 边界的限制这几条边界我都踩过列出来省你时间。第一WHERE、GROUP BY、HAVING里都不能直接用窗口函数必须包一层子查询或 CTE这是前面说过的执行顺序决定的。第二窗口函数不能嵌套ROW_NUMBER() OVER (ORDER BY SUM(x) OVER (...))这种写法会直接报错必须拆成多个 CTE 逐层计算。第三UPDATE ... SET里不能用窗口函数。想让表里的字段等于窗口计算的结果只能JOIN一个带窗口函数的派生表。而且这个派生表里不能直接引用被更新的表否则会撞上ERROR 1093解决办法同样是多包一层派生表把结果物化或者干脆先把结果落到临时表再UPDATE。第四SELECT DISTINCT和窗口函数一起用会给出反直觉的结果。因为DISTINCT发生在窗口函数之后SELECT DISTINCT col, ROW_NUMBER() OVER (...)里每一行的行号都不一样DISTINCT完全不起作用你以为去重了其实一行都没去掉。正确做法是先在子查询里用ROW_NUMBER挑出要保留的行外层再去重。6.4 版本差异与迁移时的自查项8.0 之前的版本没有窗口函数这条是硬门槛。除此之外还有几个版本细节会咬人EXPLAIN ANALYZE从 8.0.18 开始有命名窗口从 8.0.0 就有但早期小版本在继承写法上有过行为调整用户变量赋值从 8.0.13 开始标记弃用并在后续版本里逐步收紧。如果你在把一段 5.7 的用户变量代码迁移到 8.0我的建议是直接重写成窗口函数不要尝试兼容两套逻辑。写完之后准备一组边界数据跑一遍分区只有一行的、分区的排序列全部相等的、分区里存在NULL值的。NULL这个特别容易被忽略——ORDER BY col DESC时NULL排在最后ASC时排在最前如果排序列可能为空排名结果会和预期有偏差用ORDER BY col IS NULL, col DESC之类的写法显式控制位置会更稳。最后分享一个我自己的习惯每次写完带窗口函数的查询我都会先删掉外层过滤把ROW_NUMBER、RANK这些中间结果全部打印出来看一遍确认排名顺序、并列情况和分区边界都符合预期之后再把过滤条件加上。窗口函数的结果一旦错了往往错得很安静——不报错、不异常就是数字不对而且是在报表发出去之后才被发现。多花两分钟看中间结果比事后追查数据口径省事得多。
MySQL窗口函数高频面试：分组TopN、排名、帧与执行计划优化
去年秋天帮朋友做模拟面试我随手抛了一道题把每个部门薪资第二高的员工捞出来。他先写了三层嵌套子查询加一个自连接跑了几秒还漏掉了并列的情况面试官当场追问“如果并列的人有三个呢”。换成 MySQL 窗口函数这题就是DENSE_RANK()两行代码的事。窗口函数在 MySQL 8.0 之后已经不算新特性了但它依旧是数据库面试里区分度最高的一块内容——会写GROUP BY的人满地都是能说清楚帧Frame默认行为的人不多。这篇内容我打算按我自己准备面试和带新人的顺序来写先讲清楚它和聚合函数的本质差别再把语法拆成能背下来的结构然后按用途把常见窗口函数分门别类最后拿八道真实出现过的面试题逐条过一遍 SQL 和追问。不管你是刚学完基础查询想补短板还是工作几年后重新准备跳槽都能直接拿来当复习提纲。1. 从“每组取TopN”说起为什么窗口函数成了必考题1.1 一道三层子查询写出来的题暴露了什么先说那道题的具体形态。表结构很简单emp(emp_id, dept_id, name, salary)要求每个部门薪资最高的两名员工。不用窗口函数的写法通常是先按部门分组求出最高薪资再用NOT IN或者比较排除掉最高的取剩下的最大值——也就是所谓的“第二高”。这个思路在只有两三个部门、几百行数据的演示库里跑得动但一旦遇到真实数据就有三个问题同时爆发。第一个问题是并列。如果某个部门有两个人都拿 20000那“第二高”到底算谁NOT IN的写法会把两个人都排除掉最后返回第三名的薪资。第二个问题是扩展到 Top3、Top10 时SQL 的长度会随着 N 线性增长无法参数化。第三个问题是性能自连接本质上是把表跟自己做了笛卡尔积再过滤数据量上去之后索引基本失效。面试官出这道题考的不是你能不能拼出一个能跑的 SQL而是你有没有意识到“分组内排名”这个需求本身应该是数据库提供的能力。窗口函数就是这个能力的正式答案它不是语法糖而是把过去需要多次扫描、多次自连接才能表达的语义压缩成一次扫描加一次排序。1.2 GROUP BY 会塌缩行数窗口函数不会这是理解窗口函数最重要的一句话我建议你把它当成锚点记住GROUP BY是塌缩式的窗口函数是叠加式的。SELECT dept_id, AVG(salary) FROM emp GROUP BY dept_id执行完之后五行员工数据变成了三行部门数据你失去了员工个体的信息。如果这时候你既想看每个部门的平均薪资又想看每个员工自己的薪资和部门平均的对比用GROUP BY就得再关联回原表SQL 变成两段式。窗口函数的行为完全不同每一行输入对应一行输出行数不变只是在每一行后面挂了一个“基于某个窗口算出来的值”。AVG(salary) OVER (PARTITION BY dept_id)会在每个员工行上给出他所属部门的平均薪资。所谓“窗口”指的是当前行能看到的那一组行——可以是整个部门也可以是部门内排在他前面的那些人这个差别由帧来决定后面会专门拆。提示判断该用哪种问自己一句话——我输出的行数应该和输入一样吗一样就用窗口函数要收敛就用 GROUP BY。1.3 面试官问窗口函数其实在考什么我带过几个新人发现很多人背了函数名却答不上追问原因是没搞清楚考察点。按我的经验窗口函数的面试题其实在分层考察三件事。第一层是语义理解你能不能说出RANK()和DENSE_RANK()在并列时的差异这属于八股答不上来基本就凉了。第二层是帧的理解SUM(x) OVER (ORDER BY d)和SUM(x) OVER ()结果差在哪为什么LAST_VALUE会返回当前行这一层筛掉大部分人。第三层是工程判断同样的需求有没有非窗口函数的实现5.7 环境怎么办加了窗口函数之后执行计划变成什么样数据量大了会不会拖垮实例。一个能答完三层的候选人和一个只答出第一层的候选人在面试官眼里是两档人。所以下面的内容我会刻意往二三两层倾斜尤其是帧和性能这两块。2. 把语法拆成三段窗口函数的脑子怎么转2.1 OVER 括号里的三段式结构窗口函数的完整形态可以写成这样函数名(参数) OVER ( PARTITION BY 分组列 ORDER BY 排序列 帧定义 )我习惯把它当成三个可以独立回答的问题来理解。PARTITION BY回答的是“窗口的边界在哪”也就是当前行和哪些行属于同一组ORDER BY回答的是“组内怎么排序”它决定排名的顺序也影响帧的默认范围帧定义回答的是“当前行能看到组内的哪些行”也就是只看到它前面的、还是看整组。最关键的是这三段里只有OVER是必须的括号里可以写一个、两个或者三个都不写。COUNT(*) OVER ()就是整个结果集当窗口什么分区都不分这在算“全表总数占比”的时候特别好用一行都不用额外查。参数部分要单独说一下。ROW_NUMBER()、RANK()、DENSE_RANK()、NTILE(n)这类函数括号里不接字段NTILE接桶数LAG、LEAD可以接三个参数分别是表达式、偏移量、默认值写成LAG(amount, 1, 0)而SUM、AVG、COUNT、MAX、MIN直接沿用聚合函数的写法。记住这个分类写的时候不容易手滑。2.2 逻辑执行顺序为什么 WHERE 里写不了窗口函数MySQL 的逻辑执行顺序大致是FROM→WHERE→GROUP BY→HAVING→ 窗口函数计算 →SELECT列表求值 →DISTINCT→ORDER BY→LIMIT。窗口函数被安排在HAVING之后、SELECT之前意味着两件事。一是它看到的是分组之后的数据所以你可以在OVER里面套聚合函数比如SUM(SUM(amount)) OVER (PARTITION BY dept_id)先按部门汇总再加总这在算“部门销售额占公司总额比例”时很顺手。二是WHERE和HAVING的执行时机都在它之前那时候窗口函数的计算结果还不存在写上去一定会报错。报错信息通常是ERROR 3593 (HY000): You cannot use the window function row_number in this context。正确姿势是把窗口函数的结果放进子查询或 CTE在外层过滤-- 错误写法 SELECT emp_id FROM emp WHERE ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) 1; -- 正确写法 WITH ranked AS ( SELECT emp_id, dept_id, salary, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM emp ) SELECT emp_id, dept_id, salary FROM ranked WHERE rn 1;顺带提一句ORDER BY是排在窗口函数之后的所以你可以用窗口函数的别名排序也可以把窗口函数直接写在ORDER BY子句里这一点和其他很多数据库的表现一致。2.3 WINDOW 子句把重复的窗口定义收拢起来一个真实报表里往往要同时算好几个窗口指标每个OVER都抄一遍PARTITION BY dept_id ORDER BY hire_date代码会又长又容易改漏。MySQL 8.0 支持命名窗口SELECT emp_id, dept_id, salary, ROW_NUMBER() OVER w AS rn, SUM(salary) OVER w AS dept_running, AVG(salary) OVER (w ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS ma3 FROM emp WINDOW w AS (PARTITION BY dept_id ORDER BY salary DESC);命名窗口可以互相继承括号里写(w 新的帧定义)就是在已有定义上覆写帧。除了可读性它还有一个容易被忽略的好处当多个窗口定义完全相同时MySQL 只需要排一次序。我实测过几个并行窗口的查询把重复定义收进WINDOW子句之后执行计划里的排序节点数量确实会减少。分区分组逻辑不一致的时候优化器只能分别排序多出来的每一轮排序都是实打实的开销。3. 按用途分类记函数比背20个名字管用3.1 排名三兄弟ROW_NUMBER、RANK、DENSE_RANK这三兄弟的差异在面试里几乎必考我用一张表说清楚假设薪资序列是10000, 10000, 9000, 8000函数返回值特点ROW_NUMBER()1, 2, 3, 4严格递增并列时按额外规则决定先后RANK()1, 1, 3, 4并列同名次后续名次跳号DENSE_RANK()1, 1, 2, 3并列同名次后续名次不跳号选哪个完全取决于业务语义。取“每个部门薪资最高的一个人”用ROW_NUMBER()因为你不管并列就要一个代表。取“薪资排名前两档的人”用DENSE_RANK()因为你要的是“档位”而不是“个人”。取“并列都算并列后面名次空着”这种考试成绩单式的排名用RANK()。ROW_NUMBER()有个细节必须注意并列的时候它的结果是不确定的具体谁拿 1 谁拿 2 取决于扫描顺序和排序实现。如果业务上要求并列时以入职时间早的优先就得在ORDER BY里补第二个、第三个排序键写成ORDER BY salary DESC, hire_date ASC, emp_id ASC把排序键凑成唯一结果才稳定可复现。我见过线上导出报表每次数字都不一样的事故根因就是排序键不唯一。3.2 前后值函数LAG、LEAD、FIRST_VALUE、LAST_VALUELAG和LEAD是用来做相邻行比较的环比、同比、相邻两单时间差都靠它们。SELECT ym, amt, LAG(amt, 1) OVER (ORDER BY ym) AS prev_1, LAG(amt, 12) OVER (ORDER BY ym) AS prev_12 FROM monthly_sales;细节在于边界行。第一行没有前一行LAG默认返回NULL参与算术运算之后整个结果还是NULL报表上会突然出现空白。要么用第三个参数给个默认值LAG(amt, 1, 0)要么在外层用IFNULL包一层。用 0 要注意语义——把缺失值当 0 会算出 -100% 的环比报表同事多半会来找你。FIRST_VALUE和LAST_VALUE取的是窗口内第一个和最后一个值但它俩的坑不一样。FIRST_VALUE在默认帧下行为符合直觉LAST_VALUE则会让第一次用的人怀疑人生原因放在下一章细说。3.3 聚合函数挂上 OVER 之后语义的变化SUM、AVG、COUNT、MAX、MIN这五个函数一旦挂上OVER行为就从“整组汇总”变成了“窗口内汇总”。窗口范围由帧决定如果帧不写而OVER里带了ORDER BY默认帧是“从分区第一行到当前行”于是SUM自动变成了累计求和。SELECT order_date, amount, SUM(amount) OVER (ORDER BY order_date) AS running_total, COUNT(*) OVER (PARTITION BY user_id) AS user_order_cnt FROM orders;上面第一个是累计第二个是用户维度的总数因为没写ORDER BY整个分区都是窗口。这个“写不写 ORDER BY 会导致语义彻底改变”的特性是窗口函数里最容易被忽略的一点也是很多线上数字对不上的根源。再补一个高级用法聚合函数和DISTINCT组合时MySQL 8.0 支持COUNT(DISTINCT x) OVER (PARTITION BY d)用来算组内去重计数。但要注意它和SUM一起用的时候限制比较多遇到报错就退回两层查询处理。3.4 NTILE、PERCENT_RANK、CUME_DIST 什么时候真用得上NTILE(n)把分区内的行按顺序尽量均匀地切成 n 桶返回桶号。它在业务上最典型的用法是分层抽样和评分分档比如把用户按消费金额分成十档看各档的留存差异。除不尽的时候前面的桶会多一行这一点在验证数据分布时值得注意。PERCENT_RANK()返回(rank - 1) / (行数 - 1)CUME_DIST()返回的是小于等于当前值的行数占比。两者都是相对位置指标做 A/B 测试的分位数切分、算 P95 响应时间挺方便。真正算中位数最直观的还是ROW_NUMBER配COUNT我在第 5 章会给完整写法。说句实在话这三个函数在实际业务代码里出现频率远低于排名和偏移类但面试官喜欢问因为它们能证明你系统读过文档而不是只抄过例子。4. 帧Frame才是面试官真正的分水岭4.1 不带 ORDER BY 和带 ORDER BY默认帧完全不同这是全篇最值得反复读的一段。帧的默认值取决于OVER里有没有ORDER BY没有ORDER BY默认帧是ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING也就是整个分区。有ORDER BY默认帧是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW也就是从分区第一行到当前行的所有同行值。所以SUM(amount) OVER (PARTITION BY user_id)和SUM(amount) OVER (PARTITION BY user_id ORDER BY order_date)是两个完全不同的指标前者是用户总额后者是用户累计消费。差一个ORDER BY报表能差出十倍数字。显式写帧的语法是ROWS BETWEEN 起点 AND 终点起点终点可以是UNBOUNDED PRECEDING、n PRECEDING、CURRENT ROW、n FOLLOWING、UNBOUNDED FOLLOWING。常用组合就那么几个ROWS UNBOUNDED PRECEDING是累计求和的标准写法ROWS BETWEEN 6 PRECEDING AND CURRENT ROW是七日滑动平均ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING是三行平滑。提示只要你的指标涉及“累计”“滑动”“到当前为止”就把帧显式写出来。默认帧虽然能用但它是给不熟悉的人埋的雷写清楚比省几个字符值钱得多。4.2 LAST_VALUE 返回当前行不是 bug新人最常问的一个问题为什么LAST_VALUE(salary) OVER (PARTITION BY dept_id ORDER BY salary)每一行返回的都是它自己的薪资因为带了ORDER BY默认帧的终点是CURRENT ROW窗口的最后一个值就是当前行本身。这个函数在你没显式指定帧的时候行为等于什么都没做。要取分区真正的最后一行必须把帧改成ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWINGSELECT emp_id, dept_id, salary, FIRST_VALUE(salary) OVER (PARTITION BY dept_id ORDER BY salary DESC) AS top_salary, LAST_VALUE(salary) OVER (PARTITION BY dept_id ORDER BY salary DESC ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS bottom_salary FROM emp;这个知识点在面试里几乎百分百会被问到答出“默认帧终点是当前行”就够了能补一句“所以要显式改成 UNBOUNDED FOLLOWING”就是加分项。4.3 RANGE 与 ROWS 在并列数据上的分歧帧的两种模式ROWS按物理行数算RANGE按值算。默认帧用的是RANGE这一点在数据有并列时会造成非常反直觉的结果。假设某个用户一天下了三单SUM(amount) OVER (ORDER BY order_date)用默认的RANGE模式会把同一天的三单一起加进累计值所以这三行的累计结果完全相同。改成ROWS UNBOUNDED PRECEDING三行就是严格按行递增的累计。销售日报这种“一天多单”的场景两种模式算出来的曲线形状完全不一样。我的经验是做累计金额、累计订单数这类指标一律用ROWS因为它语义明确、可复现做“按时间粒度分组汇总”的语义时才考虑RANGE。另外 MySQL 对RANGE支持的是数值和时间类型的差值偏移RANGE BETWEEN INTERVAL 7 DAY PRECEDING AND CURRENT ROW这种写法在某些版本上不一定支持用之前先在你自己的环境里跑一遍。5. 八道高频题的完整解法与追问准备5.1 每部门薪资 Top2 与并列处理SELECT * FROM ( SELECT emp_id, dept_id, name, salary, DENSE_RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rk FROM emp ) t WHERE rk 2;追问一如果并列的人只能取一个怎么办把DENSE_RANK()换成ROW_NUMBER()并在ORDER BY里补hire_date或者emp_id保证唯一。追问二如果要求返回的是“薪资大于部门平均值的第二名”就得在OVER里先用AVG(salary) OVER (PARTITION BY dept_id)算均值再另起一个ROW_NUMBER注意一个 SELECT 里不能嵌套窗口函数得用两层 CTE。5.2 连续登录天数差值分组法的完整推导这题的核心技巧叫“差值分组”连续日期的特点是与行号相减之后结果恒定。WITH d AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) DAY) AS grp FROM (SELECT DISTINCT user_id, login_date FROM login_log) x ) SELECT user_id, MIN(login_date) AS start_date, MAX(login_date) AS end_date, COUNT(*) AS continuous_days FROM d GROUP BY user_id, grp HAVING COUNT(*) 3;推导过程讲清楚很加分假设某用户登录日期是 3-01、3-02、3-03行号分别是 1、2、3相减都得到 2-28说明它们属于同一个连续段。中间的 3-03 和 3-05 断开后后面那段的行号变了减出来的日期也跟着变自然形成新的分组键。两个必须注意的点第一登录表里同一天可能有多条记录内层一定要先DISTINCT否则行号会被重复记录顶偏第二login_date如果是DATETIME类型要先DATE()截断不然同一天的 09:00 和 21:00 会被当成两天。5.3 环比、同比与累计曲线的写法WITH m AS ( SELECT DATE_FORMAT(order_date, %Y-%m) AS ym, SUM(amount) AS amt FROM orders GROUP BY ym ) SELECT ym, amt, LAG(amt, 1) OVER (ORDER BY ym) AS prev_month, ROUND((amt - LAG(amt, 1) OVER (ORDER BY ym)) / NULLIF(LAG(amt, 1) OVER (ORDER BY ym), 0) * 100, 2) AS mom_pct, SUM(amt) OVER (ORDER BY ym) AS ytd_amount FROM m;这里有两个实战经验。一是除法要用NULLIF(分母, 0)兜底否则遇到零销售额的月份直接报错或者返回NULL一片用IFNULL包成 0 又会误导业务最稳妥的是让它显示为NULL加一条备注。二是月份排序不能按字符串排2024-10会排到2024-2前面%Y-%m格式恰好是定长所以能正确排序但如果你用的是%Y-%-m就会出错干脆在 CTE 里额外SELECT DATE_FORMAT(order_date,%Y-%m-01)转成日期类型再排。5.4 去重保留最新、中位数与分组占比去重保留最新一条是生产环境里用得最多的窗口函数场景DELETE FROM user_profile WHERE id IN ( SELECT id FROM ( SELECT id, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC, id DESC) AS rn FROM user_profile ) t WHERE rn 1 );这里有三层嵌套不是故意写得绕而是 MySQL 不允许在DELETE的子查询里直接引用被删的表多包一层派生表把它物化掉才能绕开限制。ORDER BY里加id DESC是为了在updated_at相同时保证结果唯一——如果没有第二排序键每次跑出来的保留记录可能不同。中位数的写法WITH r AS ( SELECT dept_id, salary, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary) AS rn, COUNT(*) OVER (PARTITION BY dept_id) AS cnt FROM emp ) SELECT dept_id, AVG(salary) AS median_salary FROM r WHERE rn IN (FLOOR((cnt 1) / 2), CEIL((cnt 1) / 2)) GROUP BY dept_id;偶数行取中间两个的平均奇数行取正中间那个用一个IN同时覆盖两种情况外层AVG自动完成合并。分组占比的写法更简单SELECT emp_id, dept_id, salary, ROUND(salary / SUM(salary) OVER (PARTITION BY dept_id) * 100, 2) AS pct_in_dept FROM emp;这题适合用来展示“从多个窗口定义里挑一个合适的帧”——占比算的是整组所以OVER里千万不能加ORDER BY加了就变成累计占比了。5.5 被追问“5.7 怎么办”时怎么答问到这一句说明面试官在考察你的知识边界。标准答案是MySQL 5.7 没有窗口函数只能用用户变量模拟。SET rn : 0, dept : NULL; SELECT emp_id, dept_id, salary, rn FROM ( SELECT emp_id, dept_id, salary, IF(dept dept_id, rn : rn 1, rn : 1) AS rn, dept : dept_id AS d FROM emp ORDER BY dept_id, salary DESC ) t WHERE rn 2;紧接着一定要补上风险用户变量的赋值和读取依赖优化器实际执行顺序SQL 里出现WHERE、JOIN、GROUP BY之后执行顺序就不再等于书写顺序结果会变得不可预测。MySQL 8.0 已经把这种用法标记为弃用。所以线上如果还在 5.7正确做法是把逻辑落到应用层做或者先物化到临时表再处理不要在生产查询里赌优化器的行为。6. 上生产前的验证清单执行计划、索引与版本差异6.1 用 EXPLAIN ANALYZE 看窗口函数到底干了什么窗口函数写得对不对是逻辑问题快不快是执行计划问题。MySQL 8.0.18 之后可以用EXPLAIN ANALYZE它会输出实际执行的行数和耗时比传统EXPLAIN更直观。带窗口函数的查询执行计划里通常能看到Window aggregate节点如果OVER里带了ORDER BY前面还会挂一个Sort节点。EXPLAIN ANALYZE SELECT * FROM ( SELECT emp_id, dept_id, salary, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM emp ) t WHERE rn 1;有个性能误区值得专门说外层的WHERE rn 1不会减少窗口函数的计算量。窗口函数在排序完成之后才逐行计算出rn派生表被物化外层过滤发生在最后一步。所以你以为“只要第一行所以很快”实际上还是全表扫加全量排序。真正想减少计算量得先在 CTE 里把数据范围缩小比如加时间条件过滤掉历史数据。6.2 排序代价与索引能不能帮上忙窗口函数最贵的部分永远是排序。当PARTITION BY的列和ORDER BY的列正好能被同一个索引覆盖时优化器有机会利用索引的有序性省掉排序如果分区和排序列分散在不同索引上那就得老老实实建临时表排序。我的经验是给窗口函数建索引时按(PARTITION BY 列, ORDER BY 列)的顺序设计复合索引例如PARTITION BY dept_id ORDER BY salary DESC对应idx(dept_id, salary DESC)就很合适。但要说清楚一点这个优化能不能生效由优化器判断不同小版本的行为也可能不同别把它当成必然还是以EXPLAIN ANALYZE实测为准。另一个容易被忽视的问题是内存。大分区排序会消耗sort_buffer_size和临时表空间超出阈值就会落盘。分区基数特别大的时候比如按用户 ID 分区查上千万用户排序中间结果会非常可观这种场景更适合先在应用层或中间表里把范围收敛下来再算。6.3 窗口函数在 UPDATE、HAVING、DISTINCT 边界的限制这几条边界我都踩过列出来省你时间。第一WHERE、GROUP BY、HAVING里都不能直接用窗口函数必须包一层子查询或 CTE这是前面说过的执行顺序决定的。第二窗口函数不能嵌套ROW_NUMBER() OVER (ORDER BY SUM(x) OVER (...))这种写法会直接报错必须拆成多个 CTE 逐层计算。第三UPDATE ... SET里不能用窗口函数。想让表里的字段等于窗口计算的结果只能JOIN一个带窗口函数的派生表。而且这个派生表里不能直接引用被更新的表否则会撞上ERROR 1093解决办法同样是多包一层派生表把结果物化或者干脆先把结果落到临时表再UPDATE。第四SELECT DISTINCT和窗口函数一起用会给出反直觉的结果。因为DISTINCT发生在窗口函数之后SELECT DISTINCT col, ROW_NUMBER() OVER (...)里每一行的行号都不一样DISTINCT完全不起作用你以为去重了其实一行都没去掉。正确做法是先在子查询里用ROW_NUMBER挑出要保留的行外层再去重。6.4 版本差异与迁移时的自查项8.0 之前的版本没有窗口函数这条是硬门槛。除此之外还有几个版本细节会咬人EXPLAIN ANALYZE从 8.0.18 开始有命名窗口从 8.0.0 就有但早期小版本在继承写法上有过行为调整用户变量赋值从 8.0.13 开始标记弃用并在后续版本里逐步收紧。如果你在把一段 5.7 的用户变量代码迁移到 8.0我的建议是直接重写成窗口函数不要尝试兼容两套逻辑。写完之后准备一组边界数据跑一遍分区只有一行的、分区的排序列全部相等的、分区里存在NULL值的。NULL这个特别容易被忽略——ORDER BY col DESC时NULL排在最后ASC时排在最前如果排序列可能为空排名结果会和预期有偏差用ORDER BY col IS NULL, col DESC之类的写法显式控制位置会更稳。最后分享一个我自己的习惯每次写完带窗口函数的查询我都会先删掉外层过滤把ROW_NUMBER、RANK这些中间结果全部打印出来看一遍确认排名顺序、并列情况和分区边界都符合预期之后再把过滤条件加上。窗口函数的结果一旦错了往往错得很安静——不报错、不异常就是数字不对而且是在报表发出去之后才被发现。多花两分钟看中间结果比事后追查数据口径省事得多。