视图可封装窗口函数，但须满足：一是仅保存逻辑不执行计算，二是窗口函数必须带over子句且不可依赖外部参数；混用group by与sum() over()会导致行数压缩后窗口失效，正确做法是视图保留明细粒度。
直接用视图封装窗口函数是可行的，但必须明确两点：一是视图本身不执行计算，只是保存查询逻辑；二是窗口函数在视图中必须带 OVER 子句且不能依赖外部参数，否则多数数据库会报错或行为异常。
视图里写 SUM() OVER() 为什么有时不生效？
常见错误是把窗口函数和聚合混用，比如在视图定义里同时写 GROUP BY 和 SUM(x) OVER(...)。数据库会先执行 GROUP BY 聚合（行数变少），再对聚合后的结果跑窗口函数——这通常不是你想要的“对原始明细行做累计”。
- 正确做法：视图只保留原始粒度（如每条订单记录），所有窗口计算都基于明细行展开
- 典型反例：
SELECT DATE(order_time), SUM(amount) OVER(...) FROM orders GROUP BY DATE(order_time)—— 这里GROUP BY已压缩行，OVER失去意义 - MySQL 8.0+ 和 PostgreSQL 允许视图含窗口函数，但 SQLite 需要启用扩展且不支持
frame_clause
怎么让视图支持按不同时间粒度滚动统计？
不能靠传参动态改粒度（SQL 标准视图不支持参数），得用固定逻辑 + 后续查询过滤。比如在视图里预计算好日级、周级、7日滚动总和三列，实际使用时只选需要的字段。
- 示例（PostgreSQL）：
CREATE VIEW order_stats AS SELECT order_id, order_time, amount, DATE(order_time) AS dt, DATE_TRUNC('week', order_time) AS wk, SUM(amount) OVER (ORDER BY order_time ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS rolling_7d_amt FROM orders; - 后续查周汇总：
SELECT wk, SUM(amount) FROM order_stats GROUP BY wk - 后续查滚动趋势：
SELECT dt, rolling_7d_amt FROM order_stats WHERE dt >= '2026-05-01' - 注意：滚动窗口依赖
ORDER BY order_time，如果原始数据时间有重复或乱序，需先用ROW_NUMBER()排序锚定
为什么 LAG() 在视图里返回 NULL 很多？
因为 LAG() 是按 ORDER BY 顺序取上一行值，而视图定义时若没指定分区，整个表会被当做一个大窗口处理——首行必然无“上一行”，且跨用户/设备的数据混排会导致业务逻辑错位。
- 必须加
PARTITION BY：比如按user_id或device_id分区，才能保证对比的是同一主体的历史值 - 示例：
LAG(amount, 1) OVER (PARTITION BY user_id ORDER BY order_time) - 时区未对齐也会放大 NULL：比如原始
order_time是 UTC，但业务要求按北京时间对齐，得先转时区再ORDER BY - 旧版 MySQL（
真正容易被忽略的是视图的物化成本——每次查询视图，窗口函数都会重算一遍。如果底层数据量大、滚动窗口宽（如 90 天累计），延迟可能陡增，这时该考虑用物化视图或定时汇总表替代。
