RANGE BETWEEN在时间列上按值域而非时间差取行，即筛选ORDER BY列值在[当前值−N, 当前值]区间内的所有行；遇重复时间戳会全量纳入导致窗口膨胀，且数据库对INTERVAL支持差异大（PostgreSQL完全支持，MySQL仅支持数值偏移），性能通常低于ROWS。
什么是 RANGE BETWEEN 在时间列上的真实行为
RANGE BETWEEN 不是“按时间差取行”，而是把时间列当作数值，按值的大小做范围比较。比如 RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW，实际效果是：对当前行的 order_time 值，筛选所有满足 order_time >= current_row.order_time - INTERVAL '7' DAY 的行（注意：仅限当前窗口分区内）。它不保证恰好 7 天内有数据就一定包含——如果某天没订单，那那天就“不存在”，不会补空；但只要时间值落在范围内，哪怕跨了十几天只有一条记录，也会被拉进来。
必须用 ORDER BY 时间列，且该列不能有重复值（或需配合 ROWS）
SQL 标准要求 RANGE 窗口必须基于单调递增/递减的 ORDER BY 表达式，且该表达式结果最好是唯一的。如果 order_time 有秒级重复（比如并发插入），RANGE 会把所有同时间戳的行“捆在一起”视为一个点——它们共享同一组前后范围结果，无法区分先后。这时你看到的滑动总和可能突然跳变，不是因为计算错，而是语义上它们被当作了“同一时刻”。
- ✅ 推荐：用
ORDER BY order_time, order_id（加唯一辅助排序），再改用ROWS BETWEEN ...避开歧义 - ⚠️ 警惕：仅
ORDER BY order_time+RANGE+ 大量重复时间 → 滑动窗口边界模糊，结果不可控 - ? 替代方案：在 PostgreSQL 中可用
GENERATE_SERIES补时间维度再 JOIN，但那是预聚合思路，不属于窗口函数原生滑动
不同数据库对 INTERVAL 的支持差异极大
RANGE BETWEEN INTERVAL 'N' UNIT PRECEDING 这种写法在标准 SQL 中存在，但实现程度五花八门：
- ✅ PostgreSQL：完全支持
INTERVAL字面量，如RANGE BETWEEN INTERVAL '30' MINUTE PRECEDING AND CURRENT ROW - ❌ MySQL（8.0.2+）：只支持数值偏移（如
RANGE BETWEEN 1800 PRECEDING），前提是ORDER BY列是 UNIX_TIMESTAMP() 转成的整数 - ⚠️ SQL Server：不支持
INTERVAL，必须用DATEADD配合子查询或 CTE 模拟，无法直接写进RANGE - ? 实操建议：先查
SELECT version()或文档确认引擎能力，别假设语法通用
性能陷阱：RANGE 在大数据时间序列上可能全表扫描
相比 ROWS BETWEEN 100 PRECEDING（固定行数、可索引跳转），RANGE BETWEEN INTERVAL '7' DAY PRECEDING 要对每行都做一次时间范围查找。若分区大、时间跨度松散（比如日志表里只有每月 1 号有数据），优化器很可能放弃索引，退化为逐行扫描+过滤。
- ✅ 优化路径：确保
ORDER BY列上有索引（如CREATE INDEX idx_orders_time ON orders(order_time)） - ⚠️ 注意：即使有索引，PostgreSQL 对
RANGE的索引利用也弱于ROWS；MySQL 更依赖函数索引（如UNIX_TIMESTAMP(order_time)） - ? 简单验证：在查询前加
EXPLAIN，看执行计划是否出现WindowAgg下挂Index Scan—— 如果是Seq Scan或Bitmap Heap Scan，就得考虑降级用ROWS+ 预处理时间戳
RANGE 按时间滑动看着直观，但背后是值域比较而非时间轴对齐；真正稳定可用的场景，往往需要数据库版本、时间精度、索引设计三者严丝合缝。稍有偏差，结果就不是“滑动”而是“跳跃”或“卡死”。
