窗口函数需将时间转为数值（如unix时间戳）后用range between定义“过去7天”等动态时间窗口；count(distinct)不被主流数据库支持，须用子查询聚合或降粒度预处理；时区与精度需统一为utc并保持一致；自连接是兼容性最好但性能较差的替代方案。
窗口函数怎么定义“特定时间窗口”
窗口函数本身不直接支持按时间范围（比如“过去7天”）动态切片，ROWS BETWEEN 或 RANGE BETWEEN 是基于行偏移或值偏移的，而时间字段通常是 datetime 类型，用 RANGE 需要配合 ORDER BY 和可排序的数值表达式。常见做法是把时间转成整数（如 Unix 时间戳、日期差），再用 RANGE BETWEEN。
例如想算“每个用户登录时刻起，往前推7天内的去重用户数”，得先构造一个可排序的数值列：
SELECT
login_time,
user_id,
COUNT(DISTINCT user_id) OVER (
ORDER BY UNIX_TIMESTAMP(login_time)
RANGE BETWEEN 7 * 86400 PRECEDING AND CURRENT ROW
) AS active_users_7d
FROM login_events;
注意：UNIX_TIMESTAMP() 在 MySQL 中可用，PostgreSQL 要用 EXTRACT(EPOCH FROM login_time)，SQLite 用 strftime('%s', login_time) —— 不同数据库时间转数值方式不同，不能直接抄。
为什么 COUNT(DISTINCT) 不能直接用于窗口函数
多数主流数据库（PostgreSQL、SQL Server、MySQL 8.0+）**不支持** COUNT(DISTINCT ...) 作为窗口函数，会报错 ERROR: DISTINCT is not implemented for window functions 或类似提示。
替代方案只有两个靠谱路径：
- 用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_time)标记每个用户首次出现，再结合外部聚合（子查询 + GROUP BY）统计； - 用
LAG()/LEAD()配合自连接或 CTE 模拟滑动去重，但性能差、逻辑绕； - 更实用的是：先按天/小时粒度聚合（
SELECT date_trunc('day', login_time) as dt, COUNT(DISTINCT user_id) AS dau FROM ... GROUP BY dt），再用窗口函数累加或取最近 N 行 —— 这不是“任意时间点窗口”，但对报表类需求足够且稳定。
如何避免时间窗口计算中的时区和精度陷阱
时间字段如果带时区（如 timestamptz），直接 ORDER BY login_time 可能因隐式转换导致排序错乱；如果字段是 datetime 无时区（MySQL 默认），又可能跨时区漏数据。
实操建议：
- 统一转为 UTC 时间再计算，例如 PostgreSQL 用
login_time AT TIME ZONE 'UTC'； - 避免用
now()或current_timestamp做窗口边界，改用固定基准时间（如业务日切点'2024-01-01'::timestamp）； - 时间精度要一致：如果原始数据精确到秒，就别用
date_trunc('hour', ...)后再算 7 天窗口，否则会丢失当天内早于某小时的记录。
替代方案：用自连接 + 时间条件模拟滑动窗口
当窗口函数受限或需要精确时间范围去重时，最可控的方式其实是非窗口写法：
SELECT t1.login_time, COUNT(DISTINCT t2.user_id) AS active_users_7d FROM login_events t1 JOIN login_events t2 ON t2.login_time BETWEEN t1.login_time - INTERVAL '7 days' AND t1.login_time GROUP BY t1.login_time;
虽然性能比窗口函数差（O(n²)），但它明确、可调试、兼容所有 SQL 引擎。关键点：
-
INTERVAL写法因数据库而异：MySQL 用DATE_SUB(t1.login_time, INTERVAL 7 DAY)，SQLite 用datetime(t1.login_time, '-7 days')； - 务必给
login_time加索引，否则慢得没法用； - 如果数据量大，考虑先按天分区或加
WHERE t1.login_time >= '2024-01-01'限制主表范围。
真正难的不是写出来，而是确认“活跃用户”的业务定义是否包含静默用户、是否要去重、时间窗口是否允许跨日合并——这些决定了你该用窗口函数还是绕开它。
