开窗函数这东西，你在数据开发、数据分析的日常SQL里几乎天天碰得到。尤其是做累计、移动平均、同比环比的时候，OVER(PARTITION BY ... ORDER BY ...)一写，结果一跑，有时候对、有时候不对，最后发现根源基本都落在ROWS和RANGE这两个窗口范围关键词上。很多人用了几年的SUM() OVER()，也不见得能把它们分清楚。老实说，我刚入行那会儿也被这俩折腾得不轻，后来花了一下午拿业务数据实测，才彻底搞明白：ROWS 是按行号圈窗口，RANGE 是按排序键的数值范围圈窗口。这篇文章会用一份简单的销售数据，把二者的区别、语法、实战场景和常见的坑，一次性讲透。不管你是数据开发、数据分析师，还是天天要跟 SQL 打交道的后端开发，照着跑一遍，基本就不会再弄混了。
1. 先搞清楚窗口函数的基本盘：窗口到底在哪里
1.1 窗口函数和 GROUP BY 聚合函数，别搞混了
窗口函数（也叫分析函数，Window Function）做的事情，从名字上看像是在给每一行数据“开一个窗口”。它与 GROUP BY 最大的不同在于：GROUP BY 会把符合条件的多行合并成一行，窗口函数却不会改变原始表的行数，它只是在每一行旁边额外多算一个值。比如你想知道每个部门的工资总额，同时还想保留每个员工自己的姓名和工资明细，用 GROUP BY 就只能得到部门汇总，员工明细就消失了；但用SUM(salary) OVER(PARTITION BY dept_id)，每一行都会多出一列“部门总工资”，明细行原地不动。
这个特性非常重要，尤其是做报表、做数据分析时，你经常需要在明细数据上叠加汇总值，去做占比、累计、对比。窗口函数就是为此设计的。而且它还有一个优势：聚合计算的范围不是固定的一整张表，而是可以动态定义的“分区+窗口”。分区由 PARTITION BY 控制，窗口则由 ORDER BY 配合 ROWS/RANGE 进一步收缩范围。
很多初学者会把 MAX()、SUM() 这种聚合函数和开窗函数混在一起，其实真正的“开窗”动作发生在 OVER 子句里。OVER 括号里的内容，才决定这个窗口函数在哪些行上计算。窗口函数可以是常见的 SUM、AVG、COUNT、MIN、MAX，也可以是 ROW_NUMBER、RANK、DENSE_RANK、LAG、LEAD 这类专用的分析函数。前者配合 OVER 使用时，就是对“窗口内的行”做聚合；后者配合 OVER 使用时，只能读取窗口内的某些行，但一般不会受到 ROWS/RANGE 的精细控制，后面我会专门讲这一点。
1.2 一个最容易被忽略的语法部件：窗口子句
窗口函数的标准语法长这样：
函数名() OVER ( [PARTITION BY 列1, 列2, ...] [ORDER BY 排序列 [ASC|DESC]] [窗口子句] )很多人在工作中只写前面两行，比如SUM(amount) OVER(PARTITION BY store_id ORDER BY sale_date)，觉得已经够了。其实这里还隐藏着一个“窗口子句”（Frame Clause）没写。窗口子句就是用来定义“窗口范围”的，也就是我们这篇文章的主角：ROWS 和 RANGE 所在的区域。
窗口子句的完整格式是：
ROWS | RANGE BETWEEN <下边界> AND <上边界>常见的边界写法有：
CURRENT ROW：当前行UNBOUNDED PRECEDING：分区第一行UNBOUNDED FOLLOWING：分区最后一行n PRECEDING：往前 n 行（ROWS）或 n 个单位值（RANGE）n FOLLOWING：往后 n 行（ROWS）或 n 个单位值（RANGE）
如果你只写了 ORDER BY，但没有写窗口子句，SQL 标准规定默认使用RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，也就是“从分区第一行到当前行的所有行，按排序键值范围计算”。这就是为什么很多人写SUM(amount) OVER(ORDER BY date)想求累计，结果遇上有重复日期时，累计结果会突然“跳”一下，因为默认的 RANGE 把所有相同日期的行看成了一个整体。
反过来说，如果没有写 ORDER BY，那么整个分区就是默认窗口，RANGE 和 ROWS 都没有意义，因为窗口是“整个分区所有行”。这个细节很多人没注意，等后面遇到坑再回来查，就会很痛苦。这里还要提醒一句：不同数据库对默认窗口的实现虽然大体一致，但细节上可能有差异。所以最安全的写法是：当你对窗口范围有明确要求时，一定不要省略窗口子句，把 ROWS/RANGE 写出来，让执行计划跟着你的意图走。
2. 窗口范围的两大主角：ROWS 和 RANGE 到底有什么区别
2.1 ROWS：按“物理行数”圈地
ROWS 是最直观的窗口定义方式：它根据“当前行”在分区中的物理位置，往前或往后数多少行，作为窗口的边界。所谓物理位置，就是结果集排序后每行所在的行号。比如ROWS BETWEEN 2 PRECEDING AND CURRENT ROW，意思是“当前行往前数 2 行，一直到当前行”，一共最多 3 行。
如果你对生活场景类比，ROWS 相当于排队时你说“往前数三个人”。不管是高矮胖瘦、什么身份，只要站在第几个位置，就会被划进窗口。所以 ROWS 完全不关心排序字段的值是多少，只关心这些行在排序后的物理位置。
ROWS 的边界用数字来表达，比如 1 PRECEDING、2 FOLLOWING。它要求 ORDER BY 后的排序结果稳定，否则“位置”会随着排序键的微小变化而变化。但在同一个查询中，只要你 ORDER BY 写清楚，行号就是确定的。MySQL 8.0、PostgreSQL、SQL Server、Oracle 都支持这种写法。
使用 ROWS 的典型场景是移动平均、滑动求和。比如要算每笔订单过去 3 笔订单的平均金额，用ROWS BETWEEN 3 PRECEDING AND CURRENT ROW，非常干净。因为你需要的就是“物理上前 3 行”，而不是“某个值范围的若干行”。
2.2 RANGE：按“排序键值”圈地
RANGE 就不一样了。它不是按行数数格子，而是按“排序键的值范围”来决定窗口。什么叫值范围？比如你按日期排序，RANGE BETWEEN INTERVAL 1 DAY PRECEDING AND CURRENT ROW，意思就是“从当前日期往前推 1 天，到今天，这个日期区间里的所有行”，不管区间里有多少行，哪怕只有一行，或者有几百行，都被包含进来。
再举个例子：按分数排序，RANGE BETWEEN 5 PRECEDING AND CURRENT ROW，意思是“分数在当前值减去 5 到当前值之间的所有行”。如果有两个学生都是 90 分，那么在计算某个 85 分的学生的窗口时，两个 90 分的学生不会进来，因为 90 超过了 85；但如果当前行是 90 分，那么所有 85~90 之间的学生都会被算进来，包括其他 90 分的学生。
这就是 RANGE 和 ROWS 最核心的差异：ROWS 是“物理行号连续”，RANGE 是“逻辑值连续”。相同排序键的行在 RANGE 中会被当成一个整体，要么同时进窗口，要么同时出窗口，中间不会被切开。所以当你看到默认窗口下累计求和遇到重复日期会一次性并入多行时，就是因为底层是 RANGE。
使用 RANGE 的典型场景是时间序列分析，比如近 7 天销量、近 30 天用户活跃数、按价格区间累计。这类需求本质上和“值”有关，和“行数”无关，用 RANGE 才符合业务直觉。
2.3 一张表把区别说透
我整理了 ROWS 和 RANGE 的对比，方便你以后快速查阅：
| 对比维度 | ROWS | RANGE |
|---|---|---|
| 边界依据 | 物理行号偏移 | 排序键的值偏移 |
| 是否关心排序键重复 | 不关心，按行独立处理 | 关心，相同键值的行会捆绑进出窗口 |
| 支持 ORDER BY 列数 | 基本无限制 | 多数数据库只允许单列，且需数值/日期/时间类型 |
| 典型语法 | ROWS BETWEEN 2 PRECEDING AND CURRENT ROW | RANGE BETWEEN INTERVAL 2 DAY PRECEDING AND CURRENT ROW |
| 适合场景 | 移动平均、滑动N行 | 近N天、按数值范围聚合 |
| 默认行为 | 需要显式声明 | 很多数据库默认未写窗口子句时使用它 |
| 性能开销 | 相对轻 | 对排序键值做范围判断，可能更重 |
这张表不是最终真理，但能覆盖 90% 的实际场景。你只要记住：看到 ROWS 想“行数”，看到 RANGE 想“值域”，后面再遇到问题就都能顺着这个思路排查。
3. 图文详解：用一份销售数据把 ROWS 和 RANGE 跑一遍
3.1 准备一份测试数据
空讲概念没有用，我拿一份很简单的销售订单表来跑。表结构就三个字段，一个日期、一个金额，再加一个自增序号方便观察。
CREATE TABLE sales ( id INT, order_date DATE, amount DECIMAL(10,2) ); INSERT INTO sales VALUES (1, '2024-01-01', 100.00), (2, '2024-01-01', 150.00), (3, '2024-01-02', 200.00), (4, '2024-01-04', 300.00), (5, '2024-01-05', 250.00), (6, '2024-01-05', 400.00);你注意到没有，1月1日有两条记录，1月5日也有两条。这种重复日期正是区分 ROWS 和 RANGE 最好的测试数据。如果你的业务表里日期连续、唯一，ROWS 和 RANGE 的结果往往一样，那你就永远发现不了区别；遇到重复值，真相一下子就浮出水面了。接下来我们分别用不同的窗口子句跑查询，我会把结果显示成表格，你自己也可以在本地数据库里复现。
3.2 实战一：累计求和，默认窗口和 ROWS 窗口的差异
先跑一个最常见的累计求和。为了让每行的物理位置看得清清楚楚，我在 SELECT 里加了一列 ROW_NUMBER()，它的作用是按 order_date 排序后给每行打一个 1、2、3 这样的序号。
SELECT order_date, amount, ROW_NUMBER() OVER (ORDER BY order_date) AS rn, SUM(amount) OVER (ORDER BY order_date) AS default_sum, SUM(amount) OVER (ORDER BY order_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS rows_cum FROM sales;把这条查询在 MySQL 8.0 里跑完，得到的结果是这样的，我加上了 rn 列作为行号参考。
| order_date | amount | rn | default_sum | rows_cum |
|---|---|---|---|---|
| 2024-01-01 | 100.00 | 1 | 250.00 | 100.00 |
| 2024-01-01 | 150.00 | 2 | 250.00 | 250.00 |
| 2024-01-02 | 200.00 | 3 | 450.00 | 450.00 |
| 2024-01-04 | 300.00 | 4 | 750.00 | 750.00 |
| 2024-01-05 | 250.00 | 5 | 1400.00 | 1000.00 |
| 2024-01-05 | 400.00 | 6 | 1400.00 | 1400.00 |
注意看第一行和第二行：rn=1 的那行 default_sum 为什么是 250？因为它用了默认的 RANGE 窗口，而 1月1日这个日期有两行，RANGE 窗口会把相同日期的两行打包成一个整体。于是第一行计算时，第二行虽然还没轮到，但已经因为“日期键值相同”被拉进了窗口。第二行计算时，还是这两行，结果也是 250。你可以把 RANGE 理解成“按日期值分组看累计”，相同日期必须同时处理。
而 rows_cum 这一列用 ROWS 窗口，严格按物理行号累计：第一行只有自己，所以是 100；第二行才是 100+150=250。从第三行开始，日期没有重复，两列结果一致。到了第五、六行，又是重复日期，default_sum 在第五行直接跳到 1400，因为它把第五、第六行两笔 250 和 400 合并进窗口了；而 rows_cum 先到 1000，再到 1400。
如果你原本只想要“逐行累计”，这里默认的 RANGE 结果会给你带来不少困扰。所以我的第一建议就是：累计求和时，如果想按物理行累计，一定要显式写ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。
3.3 实战二：近两日统计，ROWS 和 RANGE 结果差在哪
接着看一个更像业务场景的需求：我想统计“当前日期往前推 1 天（含当天）的销售额累计”。这种需求你用 ROWS 就不太对了，因为我们缺失了 1月3日的数据，物理上往前推 1 行并不代表“前一天”。我们对比一下：
SELECT order_date, amount, SUM(amount) OVER (ORDER BY order_date RANGE BETWEEN INTERVAL 1 DAY PRECEDING AND CURRENT ROW) AS range_2d, SUM(amount) OVER (ORDER BY order_date ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS rows_2row FROM sales;执行后得到这样的结果：
| order_date | amount | range_2d | rows_2row |
|---|---|---|---|
| 2024-01-01 | 100.00 | 250.00 | 100.00 |
| 2024-01-01 | 150.00 | 250.00 | 250.00 |
| 2024-01-02 | 200.00 | 450.00 | 350.00 |
| 2024-01-04 | 300.00 | 300.00 | 500.00 |
| 2024-01-05 | 250.00 | 950.00 | 550.00 |
| 2024-01-05 | 400.00 | 950.00 | 650.00 |
逐行看 range_2d 这一列：第一、二行还是 250，因为窗口日期区间是 2023-12-31 到 2024-01-01，只有 1月1日的两行；第三行是 1月2日，窗口从 1月1日到 1月2日，于是 100+150+200=450；第四行是 1月4日，窗口从 1月3日到 1月4日，1月3日没有数据，所以只有 300；第五、六行都是 1月5日，窗口从 1月4日到 1月5日，包含 300、250、400，合计 950。
再看 rows_2row 这列：第三行是第二行（150）加第三行（200），所以是 350；第四行是第三行（200）加第四行（300），所以是 500。它根本不管日期是否连续，数的是物理行。
这就是 RANGE 在时间窗口上的价值：它能真正做到“按时间值累计”，把缺失日期自动跳过去。如果你用 ROWS 去算“近N日”，数据一旦缺几天，结果就开始失真。所以，移动平均用 ROWS，时间衰减和近N日统计用 RANGE，这是最朴素的选型规则。
3.4 实战三：RANGE 按数值区间筛选行，ROWS 做不到
除了日期，RANGE 也经常用在数值列上。我用一个学生成绩表来演示，这个需求是“统计当前分数往低 5 分范围内所有学生的总分”。
CREATE TABLE scores ( id INT, score INT ); INSERT INTO scores VALUES (1, 80), (2, 85), (3, 90), (4, 95), (5, 88), (6, 82);查询如下：
SELECT id, score, SUM(score) OVER (ORDER BY score RANGE BETWEEN 5 PRECEDING AND CURRENT ROW) AS range_sum, SUM(score) OVER (ORDER BY score ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS rows_sum FROM scores ORDER BY score;跑出来的结果：
| id | score | range_sum | rows_sum |
|---|---|---|---|
| 6 | 80 | 80 | 80 |
| 1 | 82 | 162 | 162 |
| 5 | 85 | 247 | 167 |
| 2 | 88 | 173 | 173 |
| 3 | 90 | 263 | 178 |
| 4 | 95 | 185 | 185 |
看 score=85 这一行的 range_sum=247，窗口是分数 80~85，包含 80、82、85 三行，80+82+85=247。而 rows_sum 只取“物理上一行 + 当前行”，82+85=167。两者的差异非常明显。如果你是做类似“按价格带累计”的需求，RANGE 能非常自然地把同一价格区的记录囊括进来，ROWS 则需要先知道物理行数，逻辑上绕了一个大弯。
4. 窗口范围的实际应用场景
4.1 移动平均：ROWS 滑动窗口最拿手
移动平均是 ROWS 最典型的应用场景。在日常监控里，我们经常想平滑一下每天的波动，比如算 3 日移动平均，就会写：
SELECT trade_date, amount, AVG(amount) OVER (PARTITION BY store_id ORDER BY trade_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS moving_avg_3 FROM daily_sales;这里用 ROWS 是因为“移动平均 N 日”实际上说的是“最近有记录的 N 行”。如果你用RANGE BETWEEN INTERVAL 2 DAY PRECEDING AND CURRENT ROW，遇到某个门店某天没有开门，窗口里可能只有 1 行或 2 行，平均值的分母就会忽大忽小。业务上如果你要的是“最近三个营业日”的均值，那 ROWS 就是对的。如果业务上要“自然日近 3 天”，哪怕没数据也要算 0 或者不参与平均，那才需要考虑 RANGE 或者先用日期维表补数。
我见过不少人在移动平均场景里误用 RANGE，结果发现缺失日期的窗口内行数不稳定，均线抖动特别厉害。其实不是函数错了，是“移动平均”这个词在业务里被说得太模糊了。写 SQL 前建议先和业务确认：到底是“最近 N 次交易”还是“最近 N 天”。前者用 ROWS，后者用 RANGE。
4.2 时间窗口累计：RANGE 专治“天数”统计
和移动平均相反，时间窗口累计的核心词是“自然日”，最典型的是计算近 7 天销售额、近 30 天活跃用户。这类需求天然适合 RANGE：
SELECT stat_date, SUM(amount) OVER (PARTITION BY store_id ORDER BY stat_date RANGE BETWEEN INTERVAL 6 DAY PRECEDING AND CURRENT ROW) AS sum_7d FROM daily_sales;这里RANGE BETWEEN INTERVAL 6 DAY PRECEDING AND CURRENT ROW，意思就是“从当前日期往前推 6 天，到今天”，一共 7 个自然日。不管中间有没有缺数据，它都会把落在该日期区间内的所有行都算进来。如果你用ROWS BETWEEN 6 PRECEDING AND CURRENT ROW，当你日表缺了几天数据时，窗口就会包含 7 条物理行，可能横跨了 10 个自然日，结果自然不对。
当然，RANGE 的 INTERVAL 语法在不同数据库里有细微差别。MySQL 8.0 支持INTERVAL 6 DAY PRECEDING，但要求 ORDER BY 是日期/时间类型；PostgreSQL 的语法类似；SQL Server 不支持 INTERVAL，它要用RANGE BETWEEN DATEADD(DAY, -6, stat_date) AND CURRENT ROW，但 SQL Server 对 RANGE 的限制很多，常常干脆不让你用这种写法。所以生产环境真要实现“近N天滑动汇总”，有两条路：一是用 RANGE 且能用 INTERVAL；二是用自关联或日期维度表补全后，再用 ROWS。我的经验是，如果数据库给力，RANGE 最简洁；如果限制太多，老老实实用自关联，别跟数据库死磕。
4.3 累计占比与分组排名：窗口范围怎么配合
还有一个常见场景是算帕累托图，也就是按金额从大到小累计占比。比如每个商品类目里，累计前 20% 的商品贡献了 80% 的销售额。这时候窗口函数可以这样写：
SUM(amount) OVER ( PARTITION BY category ORDER BY amount DESC ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS cumulative_amount, SUM(amount) OVER (PARTITION BY category) AS total_amount这里用 ROWS 就很合适，因为你关心的是“排好序后的物理前 N 行累计”，不是“和当前金额同样大小的行一起累计”。如果你换成默认的 RANGE，遇到相同金额的行很多时，累计一下子会吞掉好几行，会导致“前 20%”完全乱套。我踩过一次坑：库存分析表里大量商品金额恰好是 99、199 这种常见价位，RANGE 把相同价格全并进同一个窗口，累计曲线直接断崖。后来改成 ROWS 按行累计，才算正常。
再说排名函数，像 RANK、DENSE_RANK、ROW_NUMBER 其实并不受 ROWS/RANGE 的窗口范围控制。你可以在它们后面写OVER(ORDER BY score)，但如果在函数里写窗口子句，很多数据库会直接报错或忽略。这个概念容易混淆，但你只要记住：求“第几行”“第几名”这类需求不需要窗口范围，窗口范围是给 SUM、AVG、COUNT 这类聚合型窗口函数用的。
4.4 小心 LAG/LEAD 和窗口子句的配合边界
LAG 和 LEAD 这两个函数用来访问分区中相对当前行偏移 N 行的值，比如上一笔订单金额、下一个用户注册时间。它们本身是在“行偏移”的逻辑上工作的，和 ROWS/RANGE 的窗口范围不是一个维度。绝大部分数据库里，LAG(amount, 1)后面的 OVER 子句即使写了RANGE BETWEEN ...，也会被忽略，函数仍然按物理行偏移来取值。
所以，如果你想实现“跟上一条日期最近的数据比”，不能指望 LAG 加 RANGE 自动跳过缺失日期。常见做法是先用窗口函数把日期错位，或者用自关联取最近日期。这在实时数仓里算是一个高频摸坑点：明明 LAG 用了 RANGE 子句，结果数据一缺，上一条就变成了“物理上一行”，给业务方解释半天。
如果你必须用“近N天内的上一笔金额”，可以考虑先用 ROW_NUMBER 对每个自然日窗口编号，再用 LAG 结合行号差做关联；或者更粗暴一点，用关联子查询取max(order_date) < 当前日期的那一行。别一上来就把 LAG 和 RANGE 组合，容易给自己挖坑。
5. 那些年我在生产环境踩过的坑：ROWS/RANGE 问题速查
5.1 坑一：默认窗口是 RANGE，结果经常“多算”
前面已经演示过，不写窗口子句时，默认 RANGE 在排序键重复时会一次框进多行。很多业务 SQL 里写SUM(amount) OVER(ORDER BY order_date)原本以为是逐行累计，结果遇到同一天多笔订单，第一行累计就变成了“当天所有订单之和”，这在“当前行累计值”的意义上已经是错的。最稳妥的写法是显式写出窗口子句。我的规矩是：开窗函数只要涉及 SUM/AVG/COUNT 且带 ORDER BY，一律把 ROWS 或 RANGE 写完整，绝不依赖默认值。短期看起来代码啰嗦，长期维护真的能少一大半事故。
5.2 坑二：RANGE 只支持单列 ORDER BY 和特定数据类型
RANGE 的偏移量是基于单个排序键的，所以大多数数据库不允许在 RANGE 窗口下写ORDER BY 列1, 列2这种多列排序。比如 Oracle 的 RANGE 窗口如果 ORDER BY 是复合条件，通常会报 ORA-00907 这类语法错误。而且边界里的n PRECEDING，对于 RANGE 来说必须是数值单位、日期时间间隔或 INTERVAL，不能随意写其他类型。如果你需求里就是要按两个字段切窗口，比如“先按地区再按日期”，其实应该用 PARTITION BY 把地区分到不同分区，而不是在 ORDER BY 里堆列。
5.3 坑三：NULL 排序值让 RANGE 窗口变成一个“大锅”
这个坑更隐蔽。ORDER BY 排序列如果存在 NULL，不同数据库对 NULL 的排序位置处理不同：MySQL 里 NULL 默认排在最前，Oracle 里 NULL 默认排在最后。而 RANGE 窗口以排序键的值范围为依据，遇到 NULL 时就会把整个分区里所有 NULL 行都拉进同一个窗口。比如你统计每个用户的累计消费，但一部分用户的 create_time 是 NULL，那么这些 NULL 行的“窗口”可能会共享所有 NULL 行，导致累计值一次暴涨。
我的解法是：如果排序列有业务意义且可能为 NULL，先COALESCE成一个默认值，比如COALESCE(create_time, '1900-01-01')，把 NULL 合理归到一个边界值上，再开窗，避免窗口边界被 NULL 污染。
5.4 坑四：RANGE 比 ROWS 慢，大表慎用
从计算原理上看，ROWS 只需要知道每个分区的物理行偏移，实现起来更像一个计数器；RANGE 需要根据排序键的值来判断每行是否落在窗口区间，往往要做额外的范围查找或排序。在几百万行的大表上跑，这种差距会被放大。我在做离线数仓任务时遇到过：同一份 2000 万行数据，改成 ROWS 后执行时间从 5 分钟降到 40 秒。虽然影响指标还有很多，但窗口类型绝对是一个重要变量。
所以优化时有一条经验：能用 ROWS 表达的窗口尽量用 ROWS；如果业务强依赖值域窗口（近N天），先确认数据量和分区粒度，必要时通过“补齐日期 + 物理窗口”的折中方案提升性能。总之别把 RANGE 当成默认选项，除非你真的需要它。
5.5 问题速查表
| 症状 | 可能原因 | 解决方向 |
|---|---|---|
| 累计值一次跳了很多 | 默认 RANGE 把重复排序键的多行合并 | 显式写ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW |
| 近N天统计结果偏小/偏大 | ROWS 按物理行数，不是按自然天数 | 改用RANGE BETWEEN INTERVAL ... DAY PRECEDING |
| RANGE 窗口语法报错 | 排序键多列/类型不支持 | 改为单列排序，或先补日期/预处理 |
| 窗口内出现大量 NULL 行 | ORDER BY 列有 NULL，RANGE 把 NULL 值合并 | 用 COALESCE 填充默认排序键 |
| 查看执行计划发现扫了很多行 | RANGE 范围判断开销大 | 尽量改成 ROWS，或先缩小分区 |
| LAG/LEAD 结果和预期不符 | 函数本质是物理行偏移 | 别用 RANGE 限制，改用自关联或扩展逻辑 |
6. 调试窗口函数的独门技巧
6.1 给每行标行号，窗口边界一目了然
我调试 ROWS/RANGE 时，第一件事就是给结果集加一列ROW_NUMBER() OVER(ORDER BY 排序键)，把物理位置可视化。然后在自己写的窗口函数旁边，再临时加一列COUNT(*) OVER(窗口子句)，看窗口内到底有几行。这样一旦结果不对，就能快速判断是窗口框大了还是框小了，不需要对着原始数据瞎猜。说到底，ROWS 和 RANGE 的区别就是“行号区间”和“值区间”的区别，只要能打印出行号和值，一切都能对上。
6.2 先用 CTE/临时表把数据缩到最小
生产环境动辄几百万行，直接在线上库调试窗口函数很危险，也很慢。我的习惯是先写一个 CTE，把数据过滤到只包含那些“能触发异常”的样本行，比如重复日期、NULL、缺失日期。然后在样本上把多种窗口子句并列对比，像前面 3.2、3.3 那样，把 default_sum、rows_cum、range_2d 全部列出来一对比，问题就能定位。别相信文档上的理论，拿自己的数据跑一遍比什么都靠谱。
6.3 把默认行为“显式化”，生产 SQL 少踩雷
以后写任何带 ORDER BY 的聚合型窗口函数，都养成显式写全窗口子句的习惯。我自己的 SQL 模板一般是：
SUM(amount) OVER ( PARTITION BY store_id ORDER BY trade_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS cumulative_amount如果不想写，也要心里清楚系统默认是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。这个显式化的过程，就是逼自己确认“到底要按行还是按值”，把业务语义说清楚，再落成代码。最后再分享一个我踩过多次后总结的习惯：任何带 ROWS/RANGE 的窗口查询，上线前我都会把窗口边界打印出来逐行核对一遍。别嫌麻烦，窗口函数的坑，十个有九个都出在“我以为的窗口”和“实际算出来的窗口”不一致上。把这个核对流程养成肌肉记忆，能帮你省下大量排查时间。
