rows between 2 preceding and current row 严格按物理顺序取当前行及前2行共3行，不依赖值；range 则按排序列值范围匹配所有满足条件的行，易因重复值导致窗口膨胀。
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW 是怎么数行的？
它严格按物理顺序数：当前行 + 前面紧挨着的 2 行，总共 3 行。哪怕这 3 行的 ORDER BY 列值全一样（比如都是 score = 85），也只拉这 3 行，不多不少。
常见错误现象：
你看到累积和“跳变”不连续，比如第 1 行是 100、第 2 行是 180、第 3 行突然变成 250 —— 这不是 bug，是 ROWS 在逐行滑动的真实表现。
- 适用场景：需要固定样本量的统计，如“最近 3 笔订单金额总和”“过去 3 天日活用户数之和”
- 注意 ORDER BY 列必须稳定：如果用了
RANDOM()或NOW()，每次执行行序可能不同，同一行在不同查询中可能被纳入/排除窗口 - 性能影响小：数据库只需定位物理偏移，不需值比较或分组
RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW 为什么常多算？
RANGE 不数行，而是看值：以当前行的 sale_date 为锚点，往前找所有 sale_date >= CURRENT_ROW.sale_date - INTERVAL '7' DAY 的行。只要日期落在这个区间内，无论有多少行、是否重复，全进窗口。
常见错误现象：
某天有 50 笔交易，RANGE 窗口会把这 50 行全包进去；而 ROWS BETWEEN 7 PRECEDING AND CURRENT ROW 最多只取 8 行（含当前行），哪怕这 8 行跨了 30 天。
- 适用场景：“过去 7 天内所有订单总额”“价格在当前商品 ±50 元内的竞品均价”
- 关键限制：仅支持能做范围计算的类型（如
DATE、NUMERIC），STRING类型不支持INTERVAL形式 - 容易踩的坑：当
ORDER BY列含大量重复值（如按小时分桶的时间戳），RANGE会把整组重复值一次性全拉进来，导致窗口膨胀远超预期
ORDER BY 有重复值时，ROWS 和 RANGE 的累积和为啥差这么多？
核心就一句话：ROWS 把每行当独立个体，RANGE 把同值的所有行当一个逻辑单元。
示例数据（按 score 升序）：
id | score ---|------ 1 | 80 2 | 85 3 | 85 4 | 85 5 | 90
用 SUM(score) OVER (ORDER BY score ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)：
第 1 行：80
第 2 行：80+85 = 165
第 3 行：80+85+85 = 250
第 4 行：80+85+85+85 = 335
第 5 行：全加 = 425
用 RANGE 版本：
第 1 行（score=80）：80
第 2–4 行（score=85）：都看到“所有 score ≤ 85”的行 → 80+85+85+85 = 335
第 5 行（score=90）：全部 = 425
- 本质区别：ROWS 对应
ROW_NUMBER()逻辑，RANGE 对应RANK()逻辑 - 默认行为陷阱：很多引擎（如 PostgreSQL、SQL Server）未显式写
ROWS或RANGE时，默认走RANGE UNBOUNDED PRECEDING，极易导致结果与直觉不符 - 调试建议：先用
ROW_NUMBER() OVER (ORDER BY ...)和RANK() OVER (ORDER BY ...)对照看排序行为，再套窗口帧
什么时候必须用 RANGE 而不能用 ROWS？
当你关心的是“值域区间”而非“行数多少”时，ROWS 根本无法表达需求。
典型不可替代场景：
- 时间类：按自然日滚动，“过去 30 天销售额”，而不是“最近 30 条记录”——因为一天可能有上千笔交易
- 数值类：金融风控中“当前用户授信额度 ±10% 范围内的所有客户平均逾期率”
- 业务语义类：“同城市所有门店上月 GMV 中位数”，城市名是字符串，但
RANGE可配合CURRENT ROW隐式等值匹配（部分引擎支持）
但要注意：RANGE 在 Hive 和旧版 MySQL 中支持有限，且对高基数重复值敏感；若只是想“跳过重复排名”，用 DENSE_RANK() + ROWS 组合往往更可控。
最易被忽略的一点：RANGE 的边界判断依赖排序列的可比较性和确定性。一旦该列含 NULL、或来自非确定性函数（如 UUID()），整个窗口行为就不可预测，连调试都难定位。
