RANGE更适合分段计费，因其基于排序列的实际值域动态聚合（如0–100、101–500分钟），而ROWS仅按物理行序计算，易导致档位错乱、累计跳变；须配合ORDER BY连续数值列使用。
为什么 RANGE 比 ROWS 更适合分段计费场景
分段计费的核心是“按数值区间累加”，比如话费套餐：0–100分钟免费，101–500分钟 0.1元/分钟，501+分钟 0.05元/分钟。这类逻辑天然依赖**值域边界**，而非行序位置。RANGE 窗口能基于排序列的实际值（如通话时长）动态聚合同一值域内的所有行，而 ROWS 只认物理行号，强行用它会把不同价格区间的记录错误地卷入同一个窗口帧。
常见错误现象：ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 在时长乱序或存在重复值时，导致累计费用跳变、漏算价格档位。
实操建议：
-
RANGE必须配合ORDER BY使用，且排序列需是参与分段判断的连续数值（如duration、amount） - 避免在
ORDER BY中混用非数值列（如ORDER BY duration, user_id），否则RANGE退化为ROWS行为 - PostgreSQL 和 SQL Server 支持
RANGE的完整语义；MySQL 8.0+ 仅支持RANGE与UNBOUNDED或CURRENT ROW组合，不支持PRECEDING/FOLLOWING偏移量
用 RANGE BETWEEN ... AND CURRENT ROW 实现阶梯式累加计费
假设有一张通话记录表 calls，含 user_id、duration（分钟），需按用户分别计算每通电话对应的阶梯单价，并生成累计费用。
关键在于先定义价格分段逻辑，再用窗口函数对每个用户的 duration 值进行范围定位。典型写法如下：
SELECT
user_id,
duration,
-- 查找当前 duration 所属档位的单价
FIRST_VALUE(price) OVER (
PARTITION BY user_id
ORDER BY tier_start
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS unit_price,
-- 累计该用户所有 ≤ 当前 duration 的通话费用（需配合分段公式）
SUM(duration * price) OVER (
PARTITION BY user_id
ORDER BY duration
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS cumulative_cost
FROM calls
JOIN pricing_tiers ON duration >= tier_start AND duration <p>注意点：</p>
-
pricing_tiers表必须预先定义好tier_start和tier_end，不能靠窗口函数实时推导区间 -
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW会把所有duration ≤ 当前行 duration的记录纳入窗口——这正是我们想要的“≤当前时长的所有档位匹配项” - 若存在相同
duration值的多条记录，RANGE会一并包含它们；而ROWS可能只取其中一部分，造成计费不一致
处理边界重叠与空档：为什么 CASE WHEN + RANGE 要分开写
真实业务中，分段边界常有重叠（如“≤100”和“≥100”都生效）或空档（如 101–199 无定义）。这时不能指望 RANGE 自动补全逻辑，必须显式控制。
错误做法：直接在 OVER() 子句里嵌套 CASE 判断档位，会导致窗口无法正确识别排序依据，报错 window function is not allowed in window definition。
正确路径：
- 先用
CASE WHEN或JOIN将每行映射到明确档位（生成price和effective_duration） - 再用
RANGE对已确定价格的数据做范围聚合 - 对空档情况，提前用
COALESCE(..., 0)或默认档位兜底，否则SUM()会跳过 NULL 导致累计中断
例如，当某次通话 duration = 150，但定价表里只有 [0,100] 和 [200,∞)，就必须在 JOIN 前用 LEFT JOIN + COALESCE 显式赋默认价，而不是寄希望于 RANGE “猜出”该走哪档。
性能陷阱：RANGE 窗口在大数据量下的实际开销
RANGE 的本质是为每一行扫描所有满足值条件的同行，时间复杂度接近 O(n²)，远高于 ROWS 的 O(n)。当单用户记录超万行，或分区键基数低（如大量用户只有一两条记录却仍用 PARTITION BY user_id），性能会断崖式下降。
优化方向：
- 确保
ORDER BY列上有索引（如CREATE INDEX idx_calls_user_dur ON calls(user_id, duration)） - 避免在
RANGE窗口中使用高精度浮点数作为排序列（如decimal(10,6)），容易因精度误差导致边界匹配失败 - 如果只是需要“当前档位单价”，用
JOIN + LATERAL（PostgreSQL）或相关子查询可能比窗口更稳更快 - MySQL 用户尤其注意：
RANGE不支持N PRECEDING，意味着无法高效实现“最近30天滚动计费”这类需求，得换用日期范围联查
真正难的不是写出 RANGE 语法，而是想清楚哪些计算必须依赖值域聚合，哪些其实可以拆成离散档位预计算——后者往往更可控、更易测试、也更不容易在数据倾斜时崩掉。
