窗口函数不支持WHERE条件，须用外层WHERE过滤或CASE WHEN屏蔽；动态时间范围需适配数据库差异，分区键须稳定防突变。
WHERE 条件写在窗口函数外面还是里面？
窗口函数本身不支持 WHERE 子句过滤计算范围，OVER() 里也不能直接加条件。想动态控制“算哪些行进去”，必须靠外层过滤或预处理——比如先用 WHERE 筛数据，再开窗；或者用 CASE WHEN 在 ORDER BY 或聚合表达式里做逻辑屏蔽。
常见错误是以为写成 AVG(col) OVER (PARTITION BY x ORDER BY y WHERE status = 'active') 能生效，实际会报错：ERROR: syntax error at or near "WHERE"。
- 真实可行的做法只有两种：
- 外层
WHERE先过滤整行（影响所有列，包括窗口结果的输入集） - 在窗口函数内部用
CASE WHEN构造条件值，比如SUM(CASE WHEN status = 'active' THEN amount ELSE 0 END) OVER (...)
- 外层
注意：后者不会减少参与排序或分组的行数，只是让无效行贡献为 0，对 RANK()、ROW_NUMBER() 这类纯序号函数没用。
用参数化日期范围动态截断窗口帧
生产环境最常需要的是“只看最近 N 天的数据滚动计算”，比如移动平均、累计求和。这时候不能硬写死日期，得靠参数传入，但 SQL 标准里 ROWS BETWEEN 和 RANGE BETWEEN 都不接受变量——ROWS BETWEEN $n PRECEDING AND CURRENT ROW 是非法语法。
所以得换思路：
- 用
RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW（PostgreSQL / Snowflake 支持，但 MySQL 不行） - 在
PARTITION BY+ORDER BY后加ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，然后在外层用子查询或 CTE 先过滤时间范围 - 更稳妥的是把时间条件放到 JOIN 或子查询里，让窗口只“看见”你想要的时间片
举个例子：要算每个用户过去 30 天的累计订单额，别在 OVER 里动脑筋，先用 WHERE order_time >= CURRENT_DATE - INTERVAL '30 days' 把数据缩好，再开窗。
分区键变化时窗口结果突变怎么防？
动态控制窗口范围时，如果 PARTITION BY 字段在运行时可能为空、重复或跨批次不一致，会导致同一行在不同执行中被分到不同组，进而让 LAG()、LEAD() 返回错乱值——尤其在增量任务里，昨天跑正常，今天加了一条空 user_id 就崩。
典型现象：某用户连续两天登录，第二天的 LAG(login_time) 返回了另一个用户的登录时间。
关键点在于：
- 分区键必须有强业务含义且稳定，避免用
COALESCE(user_id, 'unknown')这类兜底逻辑，它会让所有空值挤进同一组 - 如果源头数据存在延迟或补发，要考虑是否加
QUALIFY ROW_NUMBER() OVER (PARTITION BY key ORDER BY ts DESC) = 1去重，而不是依赖窗口自身“覆盖” - 对于实时流场景，建议在应用层做轻量缓存，别全压给 SQL 窗口函数扛状态
MySQL 8.0 vs PostgreSQL 的 RANGE 帧兼容性差异
想用时间范围动态切窗口，比如“每行往前找 1 小时内的记录求均值”，RANGE BETWEEN INTERVAL '1 hour' PRECEDING AND CURRENT ROW 在 PostgreSQL 和 Snowflake 里能直接跑，但在 MySQL 8.0 中只支持数字类型的 RANGE（如 RANGE BETWEEN 10 PRECEDING AND CURRENT ROW），时间字段必须转成秒或毫秒才能用。
这就带来两个坑：
- 直接套用 PG 写法在 MySQL 会报错：
ERROR 3586 (HY000): Window frame 'RANGE' with time-based interval is not supported - 即便转成秒，也要小心时区：用
TIMESTAMPDIFF(SECOND, prev_ts, curr_ts)比直接减更安全 - 另一个替代方案是改用
JOIN+ 条件关联模拟，虽然慢一点，但可控性强，也方便加索引
复杂点从来不在语法多难记，而在你没意识到那个“动态范围”其实已经悄悄混进了脏数据、时区偏移、或分区键的隐式类型转换。
