滑动窗口必须用 OVER 配合 ROWS BETWEEN 或 RANGE BETWEEN；不写帧默认为累积聚合，非滑动；ROWS 按物理行序高效但不保时间连续，RANGE 按实际时间值语义准但要求排序列唯一且数据库支持。
滑动窗口必须用 OVER 配合 ROWS BETWEEN 或 RANGE BETWEEN
SQL 标准里没有“滑动窗口函数”这个独立语法，它本质是窗口函数（如 SUM、AVG）配合 OVER 子句中显式定义的帧（frame）来实现的。不写帧，默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，也就是累积聚合，不是滑动。
- 想算“最近 7 天销售额”，得写
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW（按行数）或RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW（按时间值，需列是日期类型且有序） -
ROWS看物理行序，快但不保证时间连续；RANGE看实际时间值，语义准但要求排序列唯一+支持区间计算（PostgreSQL/Oracle 支持，MySQL 8.0+ 仅部分支持RANGE+INTERVAL） - 如果时间列有重复值（比如多笔订单同秒），
RANGE帧可能意外拉宽——同一时间点的所有行都会被包进当前帧
PostgreSQL 和 MySQL 8.0+ 的 INTERVAL 写法差异很大
想按自然日滑动（如“截至今天，往前推 30 天”），不能直接套用同一套 SQL。PostgreSQL 支持 RANGE BETWEEN INTERVAL '29 days' PRECEDING AND CURRENT ROW，MySQL 则必须先生成连续日期序列或用变量模拟，否则报错 ERROR 3586 (HY000): Window frame 'RANGE BETWEEN INTERVAL ...' is not supported。
- PostgreSQL：确保
ORDER BY列是DATE或TIMESTAMP类型，且OVER中必须带ORDER BY才能用RANGE+INTERVAL - MySQL 8.0+：绕过限制的实操做法是先用
LAG/LEAD取出时间边界，再用自连接或子查询过滤；或者用DATE_SUB(CURDATE(), INTERVAL 29 DAY)做静态范围，但那就不是真正滑动了 - SQLite 不支持窗口帧中的
INTERVAL，连RANGE都只支持数值列，时间滑动得靠strftime转成整数后用ROWS
性能陷阱：没加索引 or 排序失效，滑动窗口会全表扫描
窗口函数本身不自动优化帧范围查找。如果 OVER (ORDER BY event_time) 的 event_time 没索引，或者查询里混用了 WHERE 过滤但没覆盖排序字段，数据库大概率放弃使用索引做窗口帧定位，转而走临时排序+全扫描。
- 检查执行计划：PostgreSQL 看是否有
WindowAgg节点下的Sort是否依赖Index Scan；MySQL 看EXPLAIN FORMAT=TREE里是否出现window_function下挂filesort - 复合索引建议：对常用滑动场景，建
INDEX (user_id, event_time)—— 把分组键放前，时间放后，这样每个用户的滑动窗口能局部利用索引 - 避免在
ORDER BY里用函数：比如ORDER BY DATE(event_time)会让索引失效，应提前物化日期列或用表达式索引
业务时间 vs 系统时间：时区和夏令时会让 INTERVAL 计算偏移
用 RANGE BETWEEN INTERVAL '6 days' PRECEDING 算 7 天滑动时，如果数据存的是 TIMESTAMP WITH TIME ZONE，而数据库时区设为 America/New_York，那遇到 DST 切换日（如3月12日），实际跨度可能是 139 小时或 145 小时，不是严格的 168 小时。
- 最稳做法：统一用 UTC 存储和计算，应用层负责展示时区转换
- 如果必须本地时间，PostgreSQL 可用
AT TIME ZONE强制对齐：event_time AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'，但注意这会阻止索引使用 - MySQL 没原生时区区间运算，
CONVERT_TZ返回结果无法用于RANGE帧，只能提前转换好字段并建索引
OVER 子句自动兜底。 
