滑动窗口必须用RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW配合TIMESTAMP类型排序字段，ROWS BETWEEN按行数切会导致时间范围错误；COUNT(DISTINCT)在多数数据库窗口函数中不支持，需绕路实现。
滑动窗口用 OVER 配合 RANGE BETWEEN 才对得上时间
直接用 ROWS BETWEEN 算滑动用户数，结果大概率是错的——它按行数切，不是按时间切。比如某分钟没数据，ROWS BETWEEN 5 PRECEDING AND CURRENT ROW 会漏掉真实时间范围内的用户。必须用 RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW，前提是排序字段是 TIMESTAMP 类型且索引支持（PostgreSQL/Oracle 支持；MySQL 8.0+ 要求排序字段为 DATETIME 或 TIMESTAMP，不能是字符串）。
常见错误现象：OVER (ORDER BY event_time ROWS BETWEEN ...) 在稀疏日志中返回明显偏低的数值，就是这个原因。
-
event_time必须是原生时间类型，STR_TO_DATE()或TO_TIMESTAMP()转换后要显式 CAST 成TIMESTAMP - 窗口定义里不能混用
ROWS和RANGE，否则报错 - PostgreSQL 中
INTERVAL '5 min'写法合法；MySQL 要写成INTERVAL 5 MINUTE
COUNT(DISTINCT user_id) 在窗口函数里不被多数数据库支持
想直接写 COUNT(DISTINCT user_id) OVER (...)？别试了。PostgreSQL 14+、BigQuery 支持，但 MySQL 8.0、SQL Server、早期 PostgreSQL 全都不认。硬要用，得绕路：先用 ROW_NUMBER() 标记每个用户在窗口内首次出现的位置，再对首次出现计数。
实操建议：
- 用子查询生成「每个
user_id在当前时间点前 5 分钟内是否活跃」的布尔标记，再SUM()汇总 - 更稳的写法是改用
ARRAY_AGG(DISTINCT user_id)+ARRAY_LENGTH（BigQuery/PostgreSQL），但性能随窗口扩大明显下降 - 如果数据量大且实时性要求高，建议把窗口逻辑下推到流处理引擎（如 Flink SQL 的
HOP或TUMBLING），SQL 层只做轻量聚合
窗口边界对齐影响结果一致性
滑动窗口默认以每条记录的 event_time 为右边界，左边界动态计算。这会导致同一分钟内不同事件触发的窗口覆盖范围不一致——比如 10:02:15 的记录拉取的是 [09:57:15, 10:02:15]，而 10:02:48 的记录拉取的是 [09:57:48, 10:02:48]。若需对齐到整分钟（比如所有 10:02 的统计都基于 [09:57:00, 10:02:00]），必须先做时间截断：
SELECT FLOOR(UNIX_TIMESTAMP(event_time) / 60) * 60 AS minute_key, COUNT(DISTINCT user_id) AS active_users FROM events GROUP BY minute_key
但这已不是滑动窗口，而是翻滚窗口。真要滑动+对齐，得用两层窗口：外层按对齐后的时间戳分组，内层用 RANGE 窗口查该对齐点前 N 分钟的去重用户。
高基数 user_id 下性能容易崩
当单个时间窗口内 user_id 达几十万，ARRAY_AGG(DISTINCT ...) 或子查询去重会吃光内存，查询超时。这时不能靠 SQL 硬扛。
- 优先考虑近似算法：
APPROX_COUNT_DISTINCT(user_id)（BigQuery/Spark SQL）、HLL_SKETCH_INIT（Trino） - 如果业务允许误差
- MySQL 用户基本只能导出到临时表 + 去重计数，或者改用物化视图预计算每分钟活跃用户，再用自连接算滑动和
真正难的从来不是写出语法正确的窗口函数，而是让 RANGE 真正按时间滑、让去重在千万级用户下不卡死、让结果对得上监控系统里看到的数字——这些地方一不留神就掉坑里。
