range between 按order by列的值范围划分窗口，而非行数；rows between 仅按物理行号计数。range要求单列order by、不支持null和多列排序，适用于价格、分数等数值跨度场景，时间字段需注意数据库兼容性与性能。
什么是 RANGE BETWEEN，它和 ROWS BETWEEN 有什么本质区别？
RANGE BETWEEN 按值（value）划分窗口边界，不是按行数。比如 RANGE BETWEEN 10 PRECEDING AND CURRENT ROW 表示：取所有 ORDER BY 列值在 [当前行值 - 10, 当前行值] 范围内的行，不管中间隔了多少行。
这和 ROWS BETWEEN 完全不同——后者只数行号，不看值大小。常见错误是以为 RANGE BETWEEN 2 PRECEDING 会拉回两行，结果发现窗口突然变大或为空，尤其当 ORDER BY 列有重复值或空缺时。
-
RANGE要求ORDER BY子句必须存在且只能有一列（多数数据库，如 PostgreSQL、Oracle、SQL Server 支持；MySQL 8.0+ 也支持，但对PRECEDING/FOLLOWING的数值类型有限制） - 若
ORDER BY列含NULL，该行通常被排除在所有RANGE窗口之外 - 对浮点数或时间戳做
RANGE时，注意精度问题：比如ts BETWEEN '2024-01-01'::DATE PRECEDING在 PostgreSQL 中合法，但在 MySQL 中需用INTERVAL配合DATE_SUB模拟
如何正确写一个基于金额跨度的滚动求和（例如：近万元内的订单累计）？
假设表 orders 有字段 order_id、amount、created_at，你想对每个订单，计算「金额 ≤ 当前订单 amount + 10000 且 ≥ 当前订单 amount」的所有订单的 amount 总和。
关键点在于：必须用 amount 排序，且用 RANGE：
SELECT
order_id,
amount,
SUM(amount) OVER (
ORDER BY amount
RANGE BETWEEN CURRENT ROW AND 10000 FOLLOWING
) AS rolling_sum_within_10k
FROM orders;
注意：
-
ORDER BY amount是强制的，不能换成created_at -
CURRENT ROW AND 10000 FOLLOWING表示「当前 amount 值到 amount + 10000」闭区间 - 如果想包含「前后各 5000」，得写
RANGE BETWEEN 5000 PRECEDING AND 5000 FOLLOWING，不是10000 PRECEDING AND 10000 FOLLOWING - 若某行
amount = 15000，而下一行是26000，中间跳过了 10000+ 的 gap，那26000行的窗口仍只包含自己（因为没其他行落在 [26000−5000, 26000+5000] 内）
遇到 “RANGE is not supported with multiple ORDER BY expressions” 错误怎么办？
这是明确报错，说明你写了类似这样非法的语句：
SUM(x) OVER (ORDER BY a, b RANGE BETWEEN ...)
几乎所有主流 SQL 引擎（PostgreSQL、Oracle、SQL Server、MySQL 8.0+）都不允许 RANGE 窗口搭配多列 ORDER BY。解决路径只有两个：
- 改用
ROWS BETWEEN（但语义已变，不再按值跨度，慎用） - 把多维排序“降维”：比如把
(a, b)映射为唯一可比较的标量值
示例（PostgreSQL）：ORDER BY (a * 1000000 + b)，前提是b始终 或更安全地：ORDER BY CONCAT(a::text, '_', LPAD(b::text, 10, '0'))（仅适用于字符串化后能保持序关系的场景）
另外，某些引擎（如 BigQuery）根本不支持 RANGE，此时只能用自连接或 LAG/LEAD 手动模拟，性能差很多。
时间字段上用 RANGE BETWEEN 的实际限制与替代方案
想按“过去7天内”滚动统计？别直接写 RANGE BETWEEN INTERVAL '7 days' PRECEDING —— 这在 PostgreSQL 可行，但在 MySQL 中会报错，因为 MySQL 要求 RANGE 边界必须是数字，不接受 INTERVAL。
可行做法分情况：
- PostgreSQL / Oracle：支持
RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW，但ORDER BY必须是TIMESTAMP或DATE类型列 - MySQL：只能退化为
ROWS，或改用子查询 +WHERE created_at >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)（无法向量化，无窗口函数优势） - ClickHouse：用
WINDOW FUNCTION配合intDiv(toUnixTimestamp(ts), 86400)转成天粒度整数再RANGE
最易忽略的一点：即使语法通过，RANGE 在时间字段上的性能可能比 ROWS 差一个数量级，因为无法利用索引顺序扫描，引擎往往要全排序后逐行找值域匹配。
RANGE 的真正价值只在“自然数值跨度有意义”的场景，比如信用分、温度、价格、延迟毫秒数——一旦涉及时间、ID 或复合键，就该先问一句：我是不是在用锤子拧螺丝？
