RANGE时间窗口返回NULL或结果偏小，主要因排序字段含NULL、类型非TIMESTAMP/DATE、未加INTERVAL；PostgreSQL需三要素齐全，MySQL不支持INTERVAL仅支持数值偏移。
为什么RANGE时间窗口总返回NULL或结果偏小？
大概率是排序字段含NULL、类型不对，或没加INTERVAL。RANGE对ORDER BY列要求极严：必须是非NULL的TIMESTAMP/DATE类型，且不能是字符串或整数时间戳。比如order_time VARCHAR直接参与RANGE BETWEEN INTERVAL '7 days' PRECEDING会静默失效或报错。
实操建议：
- 先用
SELECT COUNT(*), COUNT(order_time) FROM orders确认NULL占比；有NULL就加WHERE order_time IS NOT NULL - 查类型：
SELECT pg_typeof(order_time) FROM orders LIMIT 1（PostgreSQL）或DESCRIBE orders（MySQL），不是DATE/TIMESTAMP就转：CAST(order_time AS TIMESTAMP) - 别信“看起来像日期”的字符串——
'2025-03-10'是文本，RANGE没法做时间运算
PostgreSQL里RANGE BETWEEN INTERVAL怎么写才不报错？
必须三要素齐全：显式ORDER BY + INTERVAL单位 + 时间列类型匹配。漏任何一项都可能语法通过但结果错乱。
正确写法示例（PostgreSQL）：
SELECT
paid_at,
SUM(amount) OVER (
ORDER BY paid_at
RANGE BETWEEN INTERVAL '30 days' PRECEDING AND CURRENT ROW
) AS rolling_30d_sum
FROM orders
WHERE paid_at IS NOT NULL;关键点：
-
INTERVAL '30 days'不能写成INTERVAL 30 DAY（PostgreSQL不认） -
paid_at必须是TIMESTAMP WITH TIME ZONE或WITHOUT TIME ZONE，不是DATE（DATE只支持天粒度，小时级窗口会截断） - 如果
paid_at带时区，建议统一转UTC：ORDER BY paid_at AT TIME ZONE 'UTC'，避免夏令时跳变导致窗口跨度过大
MySQL 8.0+能用RANGE INTERVAL吗？
不能。MySQL 8.0+的RANGE只支持数值型偏移，不接受INTERVAL表达式。写RANGE BETWEEN INTERVAL '7 days' PRECEDING会直接报错ERROR 3586。
替代方案只有两种：
- 把时间转成天数差再用数值
RANGE：ORDER BY DATEDIFF(order_date, '1970-01-01') RANGE BETWEEN 7 PRECEDING AND CURRENT ROW（注意：order_date必须是DATE类型） - 放弃窗口函数，用相关子查询（小数据量可用）：
(SELECT SUM(amount) FROM orders s2 WHERE s2.order_date >= s1.order_date - INTERVAL 7 DAY AND s2.order_date - 别用
UNIX_TIMESTAMP()转秒数再RANGE——MySQL不支持秒级RANGE偏移，会当普通数值减法处理，结果错乱
为什么加了RANGE后查询慢得离谱？
因为RANGE要为每一行重新扫描已排序序列找值边界，而ROWS靠游标偏移O(1)定位。当ORDER BY列大量重复（比如按天聚合的DATE(created_at)），性能会断崖下跌。
验证和优化方法：
- 跑
EXPLAIN ANALYZE，看执行计划里有没有WindowAgg节点下的Range字样或双阶段Sort+Window - 查重复率：
SELECT COUNT(*) * 1.0 / COUNT(DISTINCT created_at) FROM logs，>2就危险 - 加唯一辅助排序键：
ORDER BY created_at, id，让RANGE退化为逐行行为，同时保留时间语义 - 索引必须覆盖
ORDER BY列，且不能是表达式索引（INDEX ON (created_at::date)无效）
RANGE时间窗口真正的复杂点不在语法，而在它强制你直面数据分布——重复值、NULL、精度、时区，任何一个没对齐，结果就 quietly wrong。写完别急着上线，拿真实日期范围跑一遍COUNT(*) OVER (...)，确认窗口行数是否符合预期。
