企业官网建设流程全解析

做MySQL分组统计，大多数人第一反应就是GROUP BY。这个思路本身没错，但需求一旦细化就很折磨人：分组之后还想保留每一行的明细，给组内排个名次，算一下某条记录占了整个组的多少比例，或者看组内逐日累计值，GROUP BY一聚合就把行压没了，只能子查询、自连接、临时表轮番上阵。MySQL 8.0引入的窗口函数，正是为了解决这种"既要分组计算、又要保留明细"的别扭场景而设计的——它能在不合并行的前提下，把分组计算结果追加到每一行上。

这篇内容会围绕"窗口函数做分组"这个主题，从场景定位、语法拆解讲到Top N、占比、累计、环比这些高频需求，最后还会附上我实际踩过的坑和排查记录。如果你对GROUP BY已经很熟，但窗口函数还停留在"听说过、不太会用"的阶段，这篇文章可以帮你直接把这块补上。读完之后，你大概率会把手写相关子查询的习惯丢掉。

1. 窗口函数到底解决了什么问题

1.1 一个让GROUP BY抓狂的需求

具体场景是这样的：某公司销售系统里有一张销售流水表，领导要按区域统计每个销售员的汇总业绩，并按区域排名次，排名结果还要和销售员、区域这些明细信息一起展示。用GROUP BY的话，第一步能拿到区域、销售员、汇总金额，但排名这个动作GROUP BY本身做不了，得自己想办法。

比较传统也最让人头疼的一种写法，是用相关子查询数"同区域内业绩比我高的人有几个，加一就是我的排名"。SQL写出来长这样：

SELECT t.region, t.salesperson, t.total_amount, (SELECT COUNT(*) + 1 FROM ( SELECT region, salesperson, SUM(amount) AS total_amount FROM sales_record GROUP BY region, salesperson ) t2 WHERE t2.region = t.region AND t2.total_amount > t.total_amount ) AS ranking FROM ( SELECT region, salesperson, SUM(amount) AS total_amount FROM sales_record GROUP BY region, salesperson ) t;

这段SQL能跑，但问题很明显：第一，可读性太差，维护的人看到一个嵌套一个的子查询就头大；第二，相关子查询是逐行执行的，外层有多少销售员，内层就被执行多少次，数据量一大性能立刻崩；第三，遇到并列名次还得额外想办法按并列处理，逻辑再叠一层。

用窗口函数重写之后，同样的需求变成这样：

SELECT region, salesperson, total_amount, ROW_NUMBER() OVER (PARTITION BY region ORDER BY total_amount DESC) AS ranking FROM ( SELECT region, salesperson, SUM(amount) AS total_amount FROM sales_record GROUP BY region, salesperson ) t;

两段代码放在一起对比，后者肉眼可见地简洁。窗口函数把"按区域分组"和"组内排名"两个逻辑拆得清清楚楚，后续要改排序规则、改排名方式，都只需要动OVER子句里的参数，不需要动外层结构。

1.2 窗口函数的核心思路：按组计算，但行不合并

用生活化的方式理解窗口函数，可以把它比喻成"在一叠单据上盖章"。GROUP BY的分组，是把一堆单据按区域分成若干叠，每叠最后合并成一行汇总数字；窗口函数的分组，虽然也会先把单据分成一叠一叠，但它不会把这些单据叠在一起压扁，而是给这一叠贴一张标签，比如"本叠合计100万"、"本叠里你排第2"，然后把这叠里的每一张原始单据原样还给你。所以窗口函数最根本的特点就是：结果集会保留每一行原始记录，同时每行附带一组在PARTITION BY分区范围内计算出来的值。

因为这个特点，它特别适合做"明细+分组统计"混合展示的场景。比如订单列表页既要显示每一笔订单的金额，又要显示当前这张订单所属区域的订单总额、所属客户的累计消费金额，这种需求用老写法往往要JOIN两张以上临时表，而窗口函数一条SQL就能表达清楚。

MySQL从8.0版本开始正式支持窗口函数，MariaDB从10.2开始也有。如果你还在用5.7或者更早的版本，只能靠变量模拟或者先升级再说，这个我在后面"踩坑实录"那一节会详细说怎么处理。窗口函数不是锦上添花的语法糖，它是数据库在处理"组内计算"这个维度上补齐的一块重要能力，升级版本带来的收益非常直接。

1.3 用不用窗口函数的判断清单

什么时候该用窗口函数，什么时候老老实实用GROUP BY，我整理了一个快速判断清单，按这个思路选型基本不会错：

• 需要"组内排名"，比如每个区域内销售员排名，用窗口函数。
• 需要"组内累计、移动平均"，比如按日期累加销售额，用窗口函数。
• 需要"明细行附带组汇总值"，比如每笔订单后面都显示所属区域的订单总额，用窗口函数。
• 需要"前后行对比、环比"，用LAG、LEAD这类偏移窗口函数。
• 只需要每个分组一条汇总报表，不需要明细，GROUP BY足够。
• 需要对分组结果做整体过滤，且过滤条件和每一行明细无关，考虑HAVING而不是窗口函数。

这个清单不是教条，但它能帮你快速判断该往哪个方向写。窗口函数解决的是"在分组计算的参照系下，行的维度保持完整"的问题，GROUP BY解决的是"把多行压缩成一行"的问题，两者目标不同，很多时候还需要配合使用。最典型的组合就是：先用GROUP BY把明细聚合成原子指标，再在外面套窗口函数做组内排名、占比、累计，这在后面完整案例里会看到。

2. 语法与函数分类拆解

2.1 一条SQL看全语法骨架

窗口函数的标准语法可以压缩成一行来记忆：

窗口函数(参数) OVER ( [PARTITION BY 分组列1, 分组列2, ...] [ORDER BY 排序列 ASC/DESC] [ROWS/RANGE BETWEEN 帧起点 AND 帧终点] )

三个部分各自的作用不一样。PARTITION BY指定按哪些列分组，逻辑上和GROUP BY的分组概念相似，但它不会合并行；ORDER BY指定组内排序方式，对排名类函数来说，它决定名次顺序，对聚合类窗口函数来说，它还会改变默认的计算范围，这个陷阱后面会重点讲；帧定义是在排好序的分区内进一步限定"参与计算的行的区间"，不写的时候有默认规则，也可以写成ROWS BETWEEN的形式做精确控制。

给一个最基础也最好理解的例子，统计每个区域的总销售额，同时把每行订单都保留下来：

SELECT region, salesperson, sale_date, amount, SUM(amount) OVER (PARTITION BY region) AS region_total FROM sales_record;

这条SQL跑出来，行数和平时的SELECT完全一样，只是每行多了个region_total列，同一个区域内所有行的region_total值相同。先跑通这个例子，后面加ORDER BY、加帧定义、换函数都只是在这个骨架上的变化而已。

2.2 PARTITION BY和GROUP BY到底差在哪

很多人把PARTITION BY当成"另一种GROUP BY"，这个理解对了一半，两者差着关键几步。先看执行时机：SQL的逻辑执行顺序大致是FROM → WHERE → GROUP BY → HAVING → 窗口函数 → DISTINCT → ORDER BY → LIMIT。窗口函数在GROUP BY和HAVING之后、最终输出之前执行，所以它能看到分组之后的结果，而GROUP BY看不到"未聚合的明细行"。

具体差异可以看这张对照表：

这个差异有一个很实用的推论：窗口函数可以和GROUP BY同时出现在一条SQL里，前提是窗口函数使用的是GROUP BY之后的结果。比如算每个区域的销售总额，再按总额给区域排名，可以这么写：

SELECT region, SUM(amount) AS total_amount, RANK() OVER (ORDER BY SUM(amount) DESC) AS region_rank FROM sales_record GROUP BY region;

这里窗口函数拿到的输入，是GROUP BY已经汇总好的"每区域一行"的结果集，所以ORDER BY里可以直接写SUM(amount)。这种组合写法非常常见，做区域排名、部门排名时比先套一层子查询更清爽，也是"先聚合、再开窗"思想的雏形。

2.3 ORDER BY和窗口框架：最容易翻车的地方

聚合类窗口函数（SUM、AVG、MAX、MIN、COUNT）有一个很容易被忽略的默认行为：OVER里写了ORDER BY和不写ORDER BY，计算结果可能完全不同。因为一旦OVER里出现ORDER BY，聚合窗口函数的默认帧就会从"整个分区"变成"从分区起点到当前行"，也就是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，相当于把聚合变成了累计。

举个例子，假设某个区域内三笔订单金额分别是1200、1500、800：

-- 写法A：OVER里没有ORDER BY，对整个分区计算，每行都得到区域总额 SELECT sale_date, amount, SUM(amount) OVER (PARTITION BY region) AS region_total FROM sales_record; -- 写法B：OVER里有ORDER BY，默认变成累计值 SELECT sale_date, amount, SUM(amount) OVER (PARTITION BY region ORDER BY sale_date) AS running_total FROM sales_record;

写法A中每行拿到的都是整个区域的总和3500；写法B则是按日期排序后的累计值，第一行是1200，第二行是1200+1500，第三行是1200+1500+800。两段SQL只差一个ORDER BY，业务含义就完全不同，这属于典型的"语法没错、语义错了"的坑。

更隐蔽的是RANGE和ROWS的区别。RANGE是按"排序值"划定范围，如果排序日期有重复，同一天的记录会被一起纳入当前累计帧，看起来像"跳档"；ROWS BETWEEN是按物理行严格划分，不受重复值影响。所以做累计值时，我基本会显式写成ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，而不是依赖默认行为，这样语义更清晰，也不会被数据里的重复值干扰。

帧定义常用的几种写法，我整理成了表格：

还需要提醒一句：ROW_NUMBER、RANK这些排名类函数本身不认帧定义，它们总是拿整个分区做排名；帧定义影响的主要是SUM、AVG这类聚合窗口函数。写SQL之前先搞清楚自己用的是哪类函数，很多莫名其妙的计算结果就能提前避免。

3. 分组场景实战：排名、占比、累计、环比

3.1 排名类函数三兄弟怎么选

排名类窗口函数有三个：ROW_NUMBER、RANK、DENSE_RANK。新手最容易纠结它们到底什么区别，用一个例子就能说清楚。假设某区域两名销售员业绩都是100分、第三名是98分，三种函数的结果是：

区别一句话总结：ROW_NUMBER不管并列，按顺序硬编号；RANK遇到并列会跳号；DENSE_RANK遇到并列不跳号，名次紧凑排列。

实际应用里，如果要每组取Top N并且每人只能占一个名额，用ROW_NUMBER最合适，因为即使两条记录业绩相同，也会强制给出不同序号，保证每组稳定取到N条数据。如果希望并列的记录显示同样的名次、后面的名次空出来，用RANK；如果希望名次连续紧凑，比如奖金按名次档位发放，用DENSE_RANK。我处理"每个区域业绩前2名"这类需求时，默认用ROW_NUMBER，它不会因为并列而让结果集多出记录。

很多团队会纠结到底哪个函数才是"标准排名"，其实没有唯一答案，关键看业务怎么定义并列。把三种函数都跑一遍，对比输出结果，五分钟就能确定用哪个，比在会议室争论半天有效率。

3.2 聚合窗口函数在分组里的典型应用

SUM、AVG、COUNT这些平时总跟在GROUP BY后面的聚合函数，一旦加上OVER子句，就成了聚合窗口函数，在分组场景里的玩法非常多。它们的共同点是"计算的参照系是分区内的行"，但输出时每一行原样保留，这是GROUP BY给不了的。

第一个典型应用是组内占比。领导想看每笔订单在所属区域里占了多大份额，原始表一行都不能少，可以这么写：

SELECT region, salesperson, sale_date, amount, amount / SUM(amount) OVER (PARTITION BY region) AS region_share FROM sales_record;

每行的amount除以该区域总金额，就是这条订单的区域占比。如果用GROUP BY做这个需求，需要先算区域总金额，再JOIN回原表，两步操作，临时表的关联条件一多就容易出错。窗口函数把"算总和的逻辑"直接嵌在每一行旁边，逻辑清晰得多。

第二个典型应用是组内累计。统计"每个销售员从年初到当前月份的累计销售额"，这是典型的"组内跑累计"：

SELECT salesperson, sale_date, amount, SUM(amount) OVER (PARTITION BY salesperson ORDER BY sale_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running_amount FROM sales_record;

PARTITION BY salesperson保证每个销售员独立看自己的累计，ORDER BY sale_date决定累计方向，ROWS BETWEEN把参与计算的范围限定到当前行。这里如果把帧定义省略，遇到同一天多笔记录时结果可能和直觉不一致，所以显式写帧是最稳的写法。

第三个典型应用是移动平均。判断一个区域短期销售走势，可以用最近三笔订单的平均金额做平滑：

SELECT region, sale_date, amount, AVG(amount) OVER (PARTITION BY region ORDER BY sale_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS moving_avg_3 FROM sales_record;

移动平均在零售、流量分析里非常常用，窗口函数几乎是最简洁的实现方式。换成老写法，得先给每行标上行号，再自连接到前两行，复杂度完全不在一个量级。

3.3 偏移类函数做组内对比

LAG和LEAD是一对很直观的函数，作用分别是取分区内排好序后，当前行前面第N行的值、后面第N行的值。默认N=1，也就是取上一行或下一行，也可以显式指定偏移量。

做环比时LAG是绝对主角。比如每个销售员要和自己上一个月的销售额做对比，判断业绩是涨是跌，可以这样写：

SELECT salesperson, mon, month_amount, LAG(month_amount) OVER (PARTITION BY salesperson ORDER BY mon) AS prev_month_amount, month_amount - LAG(month_amount) OVER (PARTITION BY salesperson ORDER BY mon) AS diff_amount FROM ( SELECT salesperson, DATE_FORMAT(sale_date, '%Y-%m') AS mon, SUM(amount) AS month_amount FROM sales_record GROUP BY salesperson, DATE_FORMAT(sale_date, '%Y-%m') ) t;

这里有一个很关键的点：LAG的PARTITION BY必须按销售员分，ORDER BY按月份排，这样"上一行"才真正代表"这个人上一个月的业绩"。有些人写环比时用全局排序，取出来的上一条记录是别人家的，结果完全错了。窗口函数的分区维度决定"行与行之间的关系"，这是比函数本身更重要的设计决策。

如果当前行没有上一行，比如某销售员进入系统的第一个月，LAG会返回NULL。这个NULL可以直接参与计算变成NULL，也可以用IFNULL兜底成0，或者配合COALESCE处理，具体口径要看业务需求，但一定要提前想清楚，因为NULL出现在报表里很容易被忽略。

4. 完整案例：区域月度业绩报表从需求到落地

4.1 需求背景与建表

前面把知识点拆完了，下面走一遍完整案例，看看窗口函数在真实分组需求里是怎么组合使用的。原始需求是：销售负责人要看每个区域每月的销售员业绩排行，同时要看每个人在区域内的业绩占比、从1月到当前月的累计金额、以及和上月相比的增减额，最后还要快速找到每个区域每月Top 2销售员。

我先把演示表建出来，模拟某公司的销售流水：

CREATE TABLE sales_record ( id INT PRIMARY KEY AUTO_INCREMENT, region VARCHAR(20), salesperson VARCHAR(20), category VARCHAR(20), amount DECIMAL(10,2), sale_date DATE ); INSERT INTO sales_record (region, salesperson, category, amount, sale_date) VALUES ('区域A', '销售员A', '数码', 1200.00, '2024-01-05'), ('区域A', '销售员A', '数码', 800.00, '2024-02-11'), ('区域A', '销售员B', '数码', 1500.00, '2024-01-18'), ('区域A', '销售员B', '办公', 900.00, '2024-02-02'), ('区域B', '销售员C', '数码', 2000.00, '2024-01-09'), ('区域B', '销售员C', '数码', 1100.00, '2024-02-14'), ('区域B', '销售员D', '办公', 600.00, '2024-01-25'), ('区域B', '销售员D', '数码', 1300.00, '2024-02-20'), ('区域C', '销售员E', '数码', 1800.00, '2024-01-12'), ('区域C', '销售员E', '办公', 700.00, '2024-02-08');

表结构不复杂，重点是流水明细。注意我没有在表里存"月份"字段，因为月份统计口径完全可以用DATE_FORMAT从日期里现算，这也符合实际业务中"明细表不带冗余汇总字段"的规范。

4.2 第一步：先算月度基础明细

无论后面要接多少个窗口函数，第一步永远是先把最外层逻辑需要的"原子指标"算清楚。这里原子指标就是：每个销售员每个月的销售总额。

SELECT region, salesperson, DATE_FORMAT(sale_date, '%Y-%m') AS mon, SUM(amount) AS month_amount FROM sales_record GROUP BY region, salesperson, DATE_FORMAT(sale_date, '%Y-%m') ORDER BY region, salesperson, mon;

这一步先把GROUP BY的工作做完，窗口函数下一步再叠加，整个结构会非常清晰。这也是我推荐的处理顺序：能先用GROUP BY算好的原子指标，先收成一行；窗口函数负责在已经收好的行集上做跨行、跨组的计算，而不是让窗口函数直接对着原始流水做各种复杂操作。这样出问题的时候，能快速判断是汇总错了还是窗口函数算错了。

4.3 第二步：叠加排名和区域内占比

有了月度基础表之后，区域排名和占比可以直接在上面加两个窗口函数，不需要再JOIN任何表：

SELECT region, salesperson, mon, month_amount, ROW_NUMBER() OVER (PARTITION BY region, mon ORDER BY month_amount DESC) AS rank_in_region, month_amount / SUM(month_amount) OVER (PARTITION BY region, mon) AS share_in_region FROM ( SELECT region, salesperson, DATE_FORMAT(sale_date, '%Y-%m') AS mon, SUM(amount) AS month_amount FROM sales_record GROUP BY region, salesperson, DATE_FORMAT(sale_date, '%Y-%m') ) t ORDER BY region, mon, rank_in_region;

PARTITION BY region, mon的意思是"每个区域的每个月"单独成一个分区。每个分区内排一次名、算一次总和，再拿每条记录除以这个总和，占比就出来了。以区域A 2024年1月为例，那个分区只有销售员B的1500和销售员A的1200，总额2700，所以销售员B占比约55.56%、排名1，销售员A占比约44.44%、排名2。

这种"窗口函数叠加在GROUP BY结果之上"的写法，非常符合SQL的逻辑执行顺序：子查询先把明细聚合成月度记录，外层窗口函数在已经聚合好的数据集上按区域和月份分区计算，清晰且高效。如果反过来，让窗口函数直接算原始流水，还要先处理日期格式化和重复行的问题，逻辑会乱很多。

4.4 第三步：加累计和环比，输出最终报表

最后一个需求是累计和环比。累计的口径是"销售员本人从1月到当前月份的累计金额"，所以PARTITION BY必须用salesperson，ORDER BY用mon；环比是"拿这个月和这个人的上月比"，用LAG就能取到上一行的值。

SELECT region, salesperson, mon, month_amount, ROW_NUMBER() OVER (PARTITION BY region, mon ORDER BY month_amount DESC) AS rank_in_region, month_amount / SUM(month_amount) OVER (PARTITION BY region, mon) AS share_in_region, SUM(month_amount) OVER (PARTITION BY salesperson ORDER BY mon ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS accumulated_amount, LAG(month_amount) OVER (PARTITION BY salesperson ORDER BY mon) AS prev_month_amount, month_amount - LAG(month_amount) OVER (PARTITION BY salesperson ORDER BY mon) AS diff_amount FROM ( SELECT region, salesperson, DATE_FORMAT(sale_date, '%Y-%m') AS mon, SUM(amount) AS month_amount FROM sales_record GROUP BY region, salesperson, DATE_FORMAT(sale_date, '%Y-%m') ) t ORDER BY region, mon, rank_in_region;

注意这里有四个窗口函数同时出现，每个都有自己的PARTITION BY和ORDER BY，互不干扰。排名和占比按区域+月份分区，累计和环比按销售员分区，这是这条SQL最值得体会的地方：窗口函数的维度是各自定义的，完全可以在一行SQL里混用多个不同分组维度。

如果要再输出"每个区域每月Top 2"，把上面这条SQL套一层子查询，在WHERE里过滤rank_in_region<=2就行。因为窗口函数不能直接进WHERE，必须借助派生表或者公共表表达式：

SELECT region, salesperson, mon, month_amount, rank_in_region, share_in_region, accumulated_amount, diff_amount FROM ( SELECT region, salesperson, mon, month_amount, ROW_NUMBER() OVER (PARTITION BY region, mon ORDER BY month_amount DESC) AS rank_in_region, month_amount / SUM(month_amount) OVER (PARTITION BY region, mon) AS share_in_region, SUM(month_amount) OVER (PARTITION BY salesperson ORDER BY mon ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS accumulated_amount, LAG(month_amount) OVER (PARTITION BY salesperson ORDER BY mon) AS prev_month_amount, month_amount - LAG(month_amount) OVER (PARTITION BY salesperson ORDER BY mon) AS diff_amount FROM ( SELECT region, salesperson, DATE_FORMAT(sale_date, '%Y-%m') AS mon, SUM(amount) AS month_amount FROM sales_record GROUP BY region, salesperson, DATE_FORMAT(sale_date, '%Y-%m') ) base ) filtered WHERE rank_in_region <= 2 ORDER BY region, mon, rank_in_region;

到这一步，领导要的报表从数据到逻辑全部落地，总共就几条SQL，没有一次自连接，没有一次相关子查询，性能和维护成本都远优于传统写法。整个演变过程就是"先GROUP BY出原子明细，再不断叠加窗口函数"的一步步展开，这也是我写这类需求时的标准套路。

5. 高频踩坑与排查实录

5.1 ERROR 3593：窗口函数不能直接用在WHERE里

刚上手窗口函数时我就犯过这个错，想取每组第一名，直接写：

SELECT region, salesperson, amount, ROW_NUMBER() OVER (PARTITION BY region ORDER BY amount DESC) AS rn FROM sales_record WHERE rn = 1;

MySQL直接报错，提示窗口函数不能出现在WHERE子句中。原因在于逻辑执行顺序：WHERE在窗口函数计算之前就执行了，这时候rn压根还不存在，MySQL自然不会让你引用它。正确的做法是套一层派生表，或者用WITH公共表表达式，把窗口结果先算出来，再在外面过滤：

WITH ranked AS ( SELECT region, salesperson, amount, ROW_NUMBER() OVER (PARTITION BY region ORDER BY amount DESC) AS rn FROM sales_record ) SELECT region, salesperson, amount FROM ranked WHERE rn = 1;

这个错误非常典型，几乎每个窗口函数初学者都会撞上。后来我养成了一个习惯：凡是窗口函数的结果要参与过滤，就先包一层，不要和WHERE硬刚。也别想把窗口函数塞进HAVING或JOIN的ON条件里，逻辑执行顺序决定了它还没算出来，任何前置阶段都用不了它。

5.2 忘了PARTITION BY，整个结果集变成一个组

排查别人写的SQL时，我见过最普遍的问题就是漏写PARTITION BY。比如想写组内排名，结果只写了ORDER BY：

SELECT region, salesperson, amount, RANK() OVER (ORDER BY amount DESC) AS global_rank FROM sales_record;

这种写法不是语法错，但结果是从全表角度排名，而不是从区域内部排名。如果业务要的是"每个区域的排名"，这就是典型的逻辑错误，而且很难通过报错看出来。我排查这类问题的办法是先跑一条只含ROW_NUMBER的SQL，数一下每个分区的起始行名次是不是1，如果只有整个结果集第一个行名次是1，基本可以确定是漏了PARTITION BY或者分区键写错了。

另一个相关的坑是PARTITION BY里列的顺序。如果需求是"区域+月份的排名"，PARTITION BY region, mon和PARTITION BY mon, region计算结果其实一样，因为分区只是集合划分，顺序不影响成员。但为了读SQL的人不混淆，建议保持和业务口径一致的书写顺序，比如业务说的是"按区域再按月"，就写region在前、mon在后，少让同事产生疑问。

5.3 MySQL 5.7或更老版本没有窗口函数怎么办

窗口函数在MySQL 8.0才正式提供，很多存量项目还跑在5.7上，遇到"组内排名"需求确实没有现成语法。早期的经典替代方案是用用户变量模拟，思路是先按区域和金额排序，然后用变量记住上一个区域，每读一行判断：如果区域变了就从1重新记，否则继续累加。

SELECT region, salesperson, total_amount, @rank := IF(@cur_region = region, @rank + 1, 1) AS rn, @cur_region := region AS dummy FROM ( SELECT region, salesperson, SUM(amount) AS total_amount FROM sales_record GROUP BY region, salesperson ORDER BY region, total_amount DESC ) t CROSS JOIN (SELECT @cur_region := NULL, @rank := 0) vars;

这个方案能跑，但有两个隐含前提：内层查询必须保证先按region排好序，再按金额降序排，因为变量依赖这个顺序；MySQL对SELECT列表里变量赋值的求值顺序有历史包袱，8.0之后这种行为已经被官方标记为不推荐依赖。所以我给的建议很直接：如果条件允许，优先把数据库升级到8.0及以上，别把时间花在维护变量模拟SQL上；如果确实不能升级，这个方案也只能作为过渡，别指望它在复杂SQL里稳定运行。

5.4 性能优化：索引、排序与执行计划

窗口函数不是魔法，它计算的前提是对每个分区做排序，所以性能问题大多出在排序上。用EXPLAIN看执行计划，如果出现Using filesort，基本说明窗口函数的ORDER BY没有用上索引。

优化思路有三个方向。第一，尽量让PARTITION BY和ORDER BY的列有复合索引支撑，例如经常按(region, sale_date)做分区排序，就建一个region加sale_date的联合索引。第二，减少不必要的全分区帧，比如不需要"整个分区都参与计算"时，通过ROWS BETWEEN把计算范围缩小，减少参与计算的行数。第三，注意不要在子查询里随便加DISTINCT，窗口函数结果配合DISTINCT时，MySQL有时会多一次去重排序，开销不小。

还有一个容易被忽略的点：不要在PARTITION BY或ORDER BY里套函数，比如ORDER BY DATE_FORMAT(sale_date, '%Y-%m')，列一旦被函数包住，索引基本失效。如果必须按月排序，要么单独维护一个月份字段，要么接受这个写法带来的排序代价，看数据量再权衡。窗口函数本身不是性能杀手，真正需要盯住的是底层的排序和扫描范围。

6. 一点实操心得

窗口函数刚进入MySQL生态的时候，很多人觉得它只是"高级语法糖"，用不用都行。我自己用下来最深的体会是，它彻底改变了处理分组计算类需求的思考方式：以前拿到问题先想"要不要拆两张临时表、要不要自连接"，现在会先想"这需求到底关注哪个维度、要在哪个分区内算"。GROUP BY和窗口函数不是替代关系，而是分工关系：GROUP BY负责把行压缩成报表，窗口函数负责在不动行的前提下叠加分组视角的计算。

最后分享一个小习惯：我写复杂窗口SQL，从来不直接一坨写完，而是先写一个最内层的GROUP BY基础查询，确认原子指标没问题，再一层层往上加排名、占比、累计、偏移函数，每加一层就先看结果是否符合预期。这么做的好处是，出问题的时候能立刻定位是汇总错了还是窗口函数算错了，而不是对着几百行SQL从头排查。如果你刚开始接触窗口函数，也可以用这个节奏，从最简单的SUM(amount) OVER(PARTITION BY region)开始，逐步加入排序、帧定义、多函数组合，会比一次写完整条复杂SQL踏实得多。