写SQL的人多少都遇到过这种尴尬：业务方甩过来一个需求，说要统计每个产品类别的销售额，可偏偏还要把每一笔订单的明细原样保留下来，每一行订单后面都带一列"本类别合计"。你第一反应是用GROUP BY，写完一跑，发现订单明细被压没了；换子查询关联，能出结果，但数据一大慢得让人崩溃。我当年在做某电商报表项目时被这个问题卡了整整一个下午，后来才意识到，自己缺的其实是窗口函数（Window Function）这个工具。窗口函数和GROUP BY看似都在做"分组聚合"这件事，但它们的执行逻辑和返回结果完全不同，理解这一点，很多报表需求的写法和性能表现会彻底不一样。
这篇文章就用最直白的方式把两者的核心区别拆开讲清楚，配合几个可以直接抄的实战案例，覆盖排序、累计、移动平均、同环比这类常见分析场景。不管你是刚学SQL的新手，还是整天跟报表打交道的开发，都会用得上。
1. GROUP BY到底在做一件什么事
1.1 聚合的本质是"压缩行"
先把GROUP BY的底层逻辑说透。GROUP BY的执行过程，本质上是把多行按照分组键压缩成一行：同一分组内的所有行被合并，然后通过聚合函数（SUM、COUNT、AVG、MAX、MIN等）汇总出该分组的一个计算结果。输出结果的"行数"等于"分组数"，而不是原始行数。
举个例子，订单明细表里有1000行记录，分布在10个产品类别里。执行：
SELECT category, SUM(amount) AS total_amount FROM orders GROUP BY category;得到的结果只有10行，每个类别一行。这10行里只有两个字段：类别名称和该类别总金额。任何不属于分组键、也不是聚合函数参数的字段，都不能直接出现在SELECT列表里，否则数据库会报错（或者在某些数据库的宽松模式下返回一个毫无意义的随机值）。
这意味着GROUP BY天生做了一件很"狠"的事：丢掉明细。你不可能在GROUP BY的输出里既看到每一笔订单的时间、客户、商品名称，又看到每个类别的汇总金额——这两类信息根本无法放在同一行返回结果中。
1.2 为什么GROUP BY不能保留明细行
理解了"压缩行"这个本质，你就会明白GROUP BY在很多场景下的局限。
比如业务方要求："按月份汇总销售额，同时要能随时顺着汇总结果追查哪些订单贡献了这笔销售额。"GROUP BY能给你一个12行的月度汇总表，但每行只包含月份和销售额，贡献来源是哪些具体订单，完全不可见。如果你还想看"每个月销售额排名前3的订单编号"，GROUP BY就更做不到了，因为它连单笔订单的行都无法展示，更别提为每一行做排名。
我见过很多开发者在遇到这种需求时，会选择"先GROUP BY再关联原表"的迂回方案：先算汇总，再用汇总结果JOIN回明细表。逻辑上可行，但在数据量较大时，一次查询要扫描两遍大表，性能开销成倍增长。问题的根源就在于，你用了一个"会丢失明细"的工具，又硬要找回明细，只能在外面再套一层。
用生活类比来解释：GROUP BY就像把一堆苹果按大小装进不同的筐里，你最后拿到的只有"每个筐里苹果的总重量"。筐里具体哪个苹果最好、哪个生虫了，单看这个结果是不知道的。
2. 窗口函数到底在做一件什么事
2.1 窗口函数的特点：不压缩行数
窗口函数和GROUP BY最大的不同在于，它只在你原有的每一行数据基础上，"追加"一列计算结果，原始行数一行不减。也就是说，它把聚合算出来的值复制粘贴到每一行旁边，而不是把多行合并成一行。
还是上面那个1000行订单表的例子：
SELECT order_id, category, amount, SUM(amount) OVER(PARTITION BY category) AS category_total FROM orders;输出依然是1000行，每行订单都会保留完整信息，同时在最后一列出现"该订单所属类别的总销售额"。不管这个类别下有多少笔订单，每笔订单旁边的category_total值都一样。
所以窗口函数解决的问题，正是GROUP BY解决不了的那类需求：既要明细，又要聚合值，还要让两者在每一行上同时存在。
2.2 窗口函数的三大核心组件
要真正用好窗口函数，必须理解它的语法结构，由三部分组成：PARTITION BY、ORDER BY、窗口帧（ROWS/RANGE BETWEEN）。
PARTITION BY负责划分"窗口"范围，相当于"给哪些行做分组"；ORDER BY决定窗口内的排序规则；窗口帧则控制每个计算到底覆盖窗口内的哪些行区间。
一个典型的例子：
SELECT order_id, order_date, amount, SUM(amount) OVER( PARTITION BY category ORDER BY order_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS running_total FROM orders;这个查询的结果是：每个类别内，按订单日期排序，从该类别第一笔订单到当前订单的累计销售额（running_total）。PARTITION BY category把窗口限定在同一个类别内，ORDER BY order_date决定累加顺序，ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW表示从窗口起点累加到当前行。
如果你去掉ORDER BY，只留下PARTITION BY，那么结果就退化成"每个类别的总销售额"，每个订单行上都显示同一个总数。加上ORDER BY之后，同样的SUM函数逻辑会变成"逐行累加"。这是窗口函数学习中最容易绕晕的地方——同一个聚合函数，在窗口函数中多了一个ORDER BY，语义完全不同。
3. 同一个业务需求，两种写法，结果大不相同
3.1 需求场景
用一个实际需求来做对照。假设有一张销售明细表sales，字段包括：sale_id（销售单号）、sale_date（销售日期）、region（区域）、product（商品）、amount（销售金额）。表里有10个区域、500条销售记录。
业务方提了一个很常见的双重要求：按区域统计销售总额，同时要把每条销售明细保留下来，明细行上还要显示该区域的总销售额和该区域所有销售单中金额最高的那个值。
3.2 用GROUP BY怎么写，结果长什么样
如果硬用GROUP BY，第一反应是这样的：
SELECT region, SUM(amount) AS region_total, MAX(amount) AS region_max_amount FROM sales GROUP BY region;输出10行，每行一个区域，列是"区域名、区域总销售额、区域最大单笔金额"。能做到这一步，但sale_id、sale_date、product这些明细字段一个都看不到。
如果业务方咬死说"明细也要"，就得写一个让子查询挂载上去的版本：
SELECT s.sale_id, s.sale_date, s.region, s.product, s.amount, g.region_total, g.region_max_amount FROM sales s LEFT JOIN ( SELECT region, SUM(amount) AS region_total, MAX(amount) AS region_max_amount FROM sales GROUP BY region ) g ON s.region = g.region;这个写法在逻辑上完全正确，输出500行明细，每行都带上了区域汇总值。但它有两个明显问题：第一，SQL冗长，读写效率低；第二，实际执行计划里sales表大概率会被扫描两遍，一遍用于子查询聚合，一遍用于外层查询返回明细，在几千万行的大表上，这种双扫描会带来额外的时间开销和IO压力。
3.3 用窗口函数怎么写，结果长什么样
同一需求，窗口函数的写法简洁得多：
SELECT sale_id, sale_date, region, product, amount, SUM(amount) OVER(PARTITION BY region) AS region_total, MAX(amount) OVER(PARTITION BY region) AS region_max_amount FROM sales;同样是500行输出，区域总销售额和最大单笔金额被直接追加到了每一行后面。代码量只有子查询方案的一半，而且不涉及自关联，执行计划清晰，只需要对sales表扫描一次，在内存或临时存储中完成分区聚合。
3.4 两套结果的对比
两张表放在一起对比：
| 对比维度 | GROUP BY方案 | 窗口函数方案 |
|---|---|---|
| 返回行数 | 分组数（10行） | 原始行数（500行） |
| 明细字段 | 不保留 | 完整保留 |
| 聚合值展示方式 | 一个分组一行 | 每行重复显示 |
| 代码复杂度 | 直接写简单，补明细要套子查询 | 一次到位 |
| 性能表现 | 子查询方案双扫描 | 单次扫描 |
| 适合场景 | 只需要汇总报告 | 需要明细与汇总并存 |
这个对比表值得多看几遍。很多人纠结"窗口函数和GROUP BY哪个好"，实际上下结论前先明确一个问题：你到底需不需要保留明细行。不需要，GROUP BY最合适；需要，窗口函数是不可替代的选择。
4. 窗口函数的实战能力
4.1 排名三兄弟的区分
窗口函数最出名的应用之一就是排名。ROW_NUMBER、RANK、DENSE_RANK这三个函数看起来都是排名，但结果差异很大。
SELECT product, amount, ROW_NUMBER() OVER(ORDER BY amount DESC) AS rn, RANK() OVER(ORDER BY amount DESC) AS rk, DENSE_RANK() OVER(ORDER BY amount DESC) AS drk FROM sales;假设有三笔相同金额的销售，金额都是5000元，排在最前面的是10000元。ROW_NUMBER会给出1、2、3、4这样连续的编号，谁在前谁在后由物理存储顺序决定，相同金额也会分先后；RANK会给并列的几行相同的排名2，但下一个不同金额会跳号到4；DENSE_RANK则不会跳号，并列之后下一个还是3。
实际做报表时要根据业务语义来选：排名不连续但严格反映"高于你的人数"，选RANK；排名连续、并列不占额外名次，选DENSE_RANK；纯粹需要行号定位，比如取前N条、方便分页，选ROW_NUMBER。
4.2 移动平均与滑动窗口
做数据分析的人一定绕不开移动平均。比如要计算每个商品最近3笔销售的平均金额，用来观察趋势。窗口帧这时就派上用场了：
SELECT product, sale_date, amount, AVG(amount) OVER( PARTITION BY product ORDER BY sale_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW ) AS moving_avg_3 FROM sales;ROWS BETWEEN 2 PRECEDING AND CURRENT ROW的意思是"当前行以及往前推2行"，共3行参与求均值。这个写法的优势是：每行结果都是独立计算出来的，不需要你手工维护一个滑动队列。在Python里你要写循环，在SQL里一行OVER()就搞定了。
窗口帧的选择也有讲究。默认情况下，只在PARTITION BY加ORDER BY，窗口范围是"从分区起点到当前行"，这正是做累计值（running total）的默认行为；如果需要固定窗口大小，必须显式指定ROWS BETWEEN。这两个写法若没有明确区分，特别容易把累计值错写成全局值。
4.3 同比环比：用LAG和LEAD取上一行
窗口函数里的LAG和LEAD可以从当前行往前或往后取同组内的某一行值，用这个逻辑可以做同环比。比如要计算每个月相比上个月的销售增长率：
SELECT DATE_TRUNC('month', sale_date) AS month, SUM(amount) AS month_amount, LAG(SUM(amount), 1) OVER(ORDER BY DATE_TRUNC('month', sale_date)) AS prev_month_amount, (SUM(amount) - LAG(SUM(amount), 1) OVER(ORDER BY DATE_TRUNC('month', sale_date))) / LAG(SUM(amount), 1) OVER(ORDER BY DATE_TRUNC('month', sale_date)) AS mom_growth FROM sales GROUP BY DATE_TRUNC('month', sale_date);注意这个查询的巧妙之处：先GROUP BY取月度汇总，再在汇总结果上使用窗口函数LAG。窗口函数完全可以作用在GROUP BY的结果之上，二者不是互斥关系，而是可以接力使用的。这种组合方式我在实际项目中用过无数次——先用GROUP BY把粒度聚合到月，再对聚合结果做趋势分析。
4.4 累加与份额计算
每一行占总体的百分比，是另一个高频需求：
SELECT product, amount, SUM(amount) OVER() AS total_amount, ROUND(amount * 100.0 / SUM(amount) OVER(), 2) AS pct FROM sales;SUM(amount) OVER()不带PARTITION BY，意味着把所有行放进同一个窗口，得到的是全表总金额。每一行都可以用自己的金额除以这个全局总数，得到占比。这类写法在做销售占比、品类结构分析时非常轻量，省掉一次自关联。
5. 选GROUP BY还是窗口函数：场景决策指南
5.1 GROUP BY不可替代的场景
窗口函数再强，也不可能取代GROUP BY。需要把输出结果压缩成分组报告的场景，GROUP BY是唯一正确选择。例如：
- 输出一张"区域-月份-销售额"的汇总报表，每个维度组合只占一行；
- 计算每个用户的总消费金额、订单数、客单价，结果用于后续建模或导出Excel；
- 去重、去重计数（COUNT(DISTINCT xxx)配合GROUP BY）。
原因很简单：窗口函数不压缩行数，如果明细1000万行，窗口函数输出还是1000万行，你要的是10行汇总，窗口函数做不到。它只会把那10行的汇总值重复贴到1000万行上，浪费空间和计算资源。
5.2 窗口函数不可替代的场景
反过来，凡是"每个明细行都需要关联匹配一份上下文统计信息"的需求，GROUP BY都搞不定，只能上窗口函数：
- 报表中同时展示明细和合计；
- 需要排名、取TopN；
- 移动平均、滑动累计；
- 同比、环比、与上一行比较；
- 每一行占分组的百分比。
这类需求都有一个共同特征：**计算结果依赖"同一分组内其他行的数据"，但最终输出不想丢失自己这一行。**窗口函数就是为此而生的。
5.3 性能层面的实际考量
性能上，很多人有个刻板印象，认为窗口函数一定比GROUP BY慢。这个说法不准确。
GROUP BY在聚合后会大幅减少中间结果集行数，后续处理的数据量小；窗口函数因为不压缩行，内存和磁盘临时空间的消耗会更大。但这只是账面上的比较。如果你的需求是"明细+聚合值并存"，GROUP BY被迫套一层JOIN，两次扫描的成本可能比一次窗口计算还要高。具体选择哪个，取决于你的输出目标，而不是函数本身的性能。
我自己的经验是：数据量在百万级别以内，两者性能差异几乎可以忽略；上了千万级别，需要重点看执行计划中是否出现大排序（Sort）、临时表写入（Temporary）、以及扫描次数。窗口函数里的PARTITION BY字段如果选择性很低（比如所有行都落在同一个分区），会导致单分区数据量巨大，这时候性能就会显著下降，可以考虑先用GROUP BY压缩粒度再叠加窗口函数。
6. 常见问题与实战避坑
6.1 漏写PARTITION BY导致结果全乱
窗口函数里最容易犯的错误就是漏写PARTITION BY。比如：
SELECT product, amount, SUM(amount) OVER(ORDER BY sale_date) AS running_total FROM sales;你本来想按product分组累计各商品的销售额，但因为没有PARTITION BY product，结果变成了"所有商品按日期混合累计"。每一行的running_total显示的是全表截至当前日期的累计销售额，而不是某一个商品的累计值。这个问题在数据量大的时候很隐蔽，因为不报错，只有看到某个商品行上的数值和预期对不上才能发现。
排查办法很简单：写完窗口函数后，先人肉对一下第一行和最后一行的计算结果，再用同样条件的GROUP BY交叉验证几行。
6.2 在WHERE子句里直接过滤窗口函数结果
新手最容易踩的第二个坑是试图在WHERE里过滤窗口函数的结果：
SELECT product, RANK() OVER(ORDER BY amount DESC) AS rk FROM sales WHERE rk <= 3;这个SQL会直接报错。原因在于SQL的执行顺序：WHERE在SELECT之前执行，窗口函数在WHERE之后、SELECT阶段才计算，因此WHERE看不到窗口函数的输出。想过滤排名，只能把带窗口函数的查询包成子查询或公用表表达式（CTE，即Common Table Expression）：
WITH ranked_sales AS ( SELECT product, RANK() OVER(ORDER BY amount DESC) AS rk FROM sales ) SELECT * FROM ranked_sales WHERE rk <= 3;这是窗口函数最常见的应用场景之一——取每个分组内的TopN，也是面试题里考得最多的写法，需要熟练掌握。
6.3 窗口内ORDER BY的排序字段类型
窗口函数中ORDER BY不只是为了排序，更影响窗口帧的划定、累计的先后顺序。如果排序字段是日期类型的字符串，但存的是"20250101"这种文本格式，排序时按字符串字典序排，结果可能就是20250101排在20250102前，看起来没问题，但一旦出现2月（20250201）和1月（20250101）混在一起，字典序依然正好和日期序碰巧一致；如果出现带时间的ISO格式，或者有null值混入，排序结果就和直觉相反。
稳妥做法是确保排序字段用真正的DATE/TIMESTAMP类型，或者用TO_DATE这类函数显式转换后再排。窗口函数的执行计划中通常会体现这个排序过程，遇到结果异常，优先盯这里。
6.4 把窗口函数当成GROUP BY的分组使用
窗口函数里如果只写PARTITION BY不写ORDER BY，很多人会误以为自己是在"分组"，然后试图在PARTITION BY子句中引用多个字段并把整段逻辑当作GROUP BY来嵌套使用。事实上，PARTITION BY的作用范围和粒度确实类似于GROUP BY，但区别在于行不压缩。
想同时按多个维度划分窗口，PARTITION BY region, product_date是正确的写法，JOIN键的顺序也会影响窗口划分的效率。如果发现窗口函数的结果在多个维度组合下重复出现、数值不对，回头检查PARTITION BY表达式里有没有写错字段名，或循环引用了聚合函数结果。
6.5 与DISTINCT一起使用时的理解偏差
还有个容易混淆的点是：DISTINCT和窗口函数搭配时，DISTINCT先对行去重，窗口函数再去计算，还是窗口函数先算好再去重？实际上SQL的执行逻辑里，DISTINCT发生在SELECT输出阶段，窗口函数在DISTINCT之前已经完成计算。这就意味着：
SELECT DISTINCT category, SUM(amount) OVER(PARTITION BY category) AS category_total FROM sales;窗口函数先按全部原始行计算每个类别的总金额，然后DISTINCT再对结果去重。输出里每个category一行，但category_total是原始明细全部加总后的值，不是去重后再算的。如果业务上希望"先去重再聚合"，窗口函数表达不了，需要先做子查询去重，再在外面套窗口函数。
7. 练手用的几个SQL调试技巧
纸上谈兵再多，不如动手跑一遍。我在本地经常用一组销售表的虚拟数据做窗口函数的试验场，这里给几个实用的调试思路。
第一，写任何窗口函数前，先问自己三个问题：分区是什么（PARTITION BY）、窗口内怎么排序（ORDER BY）、窗口范围是什么（ROWS BETWEEN还是默认到当前行）。三个问题都回答清楚了，代码就不会偏。
第二，先用LIMIT 20强制输出小数据量，肉眼观察结果是否符合预期。窗口函数出的错，通常在小数据量下能直接看出来，比如某个分组的第一行就没按预期给出累计值，那就是窗口帧或排序方向的问题。
第三，拿GROUP BY做交叉验证：如果你不确定窗口函数某个聚合值是否正确，先用同样的PARTITION BY和聚合函数写一版分组查询，取其中一个分组的值对比。两边的数字能对上，说明窗口函数的部分没问题。
第四，遇到大表不要死磕窗口函数。如果只是为了得到"每组的聚合值"，直接用GROUP BY；如果必须同时保留明细，且窗口性能不理想，考虑先对明细做过滤压缩，再用窗口函数，最大化减少窗口处理的行数。
第五，不同数据库的窗口函数支持程度有差异。MySQL 8.0以上版本、PostgreSQL、SQL Server、Oracle均支持标准窗口函数语法，但某些老版本MySQL（5.7及以下）完全不支持。迁库或读写分离时，得先确认目标数据库版本，否则上线才发现不兼容就很被动。
我在实际做某物流分析项目时，遇到过一个很有意思的场景：要计算每一辆配送车每天各订单的配送时长，并对比"该车当天所有订单的平均配送时长"。如果用GROUP BY，每辆车每天只出一行，根本没法逐单对比；用窗口函数，每单一行，旁边带上车辆当日平均时长，一条SQL就出了分析底表。后来这套逻辑还被复用到了多个报表里。
还有一次做零售销售额月报，业务方最开始给的模板里要"品类、月份、销售额、该品类当月占比、销售额环比"。光是"当月占比"和"环比"这两个字段，就得在GROUP BY结果外叠两层窗口函数。写完之后我自己都很感慨：如果不理解窗口函数，这个需求至少要拆三条SQL，用临时表来回倒腾，出数时间会增加好几倍。
说到底，GROUP BY和窗口函数不是谁替代谁的关系。GROUP BY负责把数据压成摘要，适合看整体；窗口函数负责在完整数据上做分析，适合看细节和趋势。理解它们的本质区别，你写SQL时能一眼判断该用什么，而不是陷入"报错了才想起来还有另一个写法"的被动循环。我的经验是，把这两者放一起对比学习，比单独看任何一方的文档效率都高得多——因为它们就像同一枚硬币的两面，一面让你看见森林，一面让你看清每棵树，而报表开发中最难的永远不是语法，而是想清楚你此刻到底需要看见什么。
