窗口函数可同时实现每日增量和累计求和：用lag()计算当日新增（需order by date并设默认值0），用sum() over(order by date)滚动累加；若日期不连续，须先补全日期序列再开窗，跨库推荐max(cum_sum) over(order by date rows unbounded preceding)替代ignore nulls。
用窗口函数实现每日增量和累计求和
直接在单条 SELECT 语句里同时拿到「当天新增值」和「截至当天的累计值」，核心是组合使用 LAG() 和 SUM() OVER()。前者取上一行数据算差值，后者按时间顺序滚动累加。
常见错误是试图用 GROUP BY date 后再套聚合函数来“手动减”，结果要么报错，要么逻辑错乱——因为 GROUP BY 会丢失行级上下文，LAG() 必须在未分组的原始行上运行。
- 必须先按日期排序（
ORDER BY date），否则LAG()和窗口SUM()都会乱序 -
LAG(value, 1, 0)的第三个参数设为0，避免首日出现NULL导致整列变NULL - 若原始数据存在多条同日期记录，需先按日期聚合（如
SUM(value) AS daily_value），再对聚合后结果开窗
处理非连续日期时的累计值断层问题
当某天无数据（比如周末没记录），SUM(value) OVER (ORDER BY date) 会自然跳过该日期，导致累计值在时间轴上“不连续”——这本身没错，但业务常要求“每天都有值”，即缺失日继承前一天累计值。
这时候不能靠窗口函数硬补，得先生成完整日期序列，再 LEFT JOIN 原始聚合结果，最后用 COALESCE() 或 LAST_VALUE(... IGNORE NULLS)（PostgreSQL/Oracle 支持）填充。
- MySQL 8.0+ 可用
WITH RECURSIVE生成日期序列；旧版得依赖日历表 - PostgreSQL 推荐用
GENERATE_SERIES()，简洁可靠 - 补完空日后，累计值必须基于补全后的结果再次开窗，不能复用原始窗口结果
不同数据库对 IGNORE NULLS 的兼容性差异
想让累计值在空日自动延续，最直觉写法是 LAST_VALUE(cum_sum) OVER (ORDER BY date ROWS UNBOUNDED PRECEDING)，但默认行为是遇到 NULL 就停住。PostgreSQL 和 Oracle 支持 IGNORE NULLS，而 MySQL 和 SQL Server 不支持。
替代方案是用 MAX(cum_sum) OVER (ORDER BY date ROWS UNBOUNDED PRECEDING) —— 因为累计值单调不减，最大值就是最近的有效累计值。这个写法跨库通用，且性能不输原生 IGNORE NULLS。
- SQL Server 2022+ 开始支持
IGNORE NULLS，但多数生产环境仍是 2019 或更早 - BigQuery 用
ARRAY_AGG(...) LIMIT 1模拟，但可读性差、易出错 - 别在 WHERE 里提前过滤掉空日，否则后续填充逻辑失效
性能敏感场景下的物化建议
如果每日增量 + 累计指标要高频查询（比如报表接口每秒调用多次），反复执行窗口计算会造成明显延迟，尤其当基础表超千万行时。
推荐把关键中间结果物化：建一张带 daily_value、delta、cum_sum 字段的汇总表，用定时任务（如每天凌晨）追加最新一天数据。这样查询时只需 SELECT * FROM daily_summary WHERE date >= ?，毫秒级响应。
- 物化时务必校验日期唯一性，避免重复跑批导致双计
- 首次全量初始化可用窗口函数一次性算完，之后只增量更新
- 如果业务允许分钟级延迟，也可以用物化视图（PostgreSQL / Oracle / Snowflake 支持）替代手工维护
实际中最容易被忽略的是日期字段的时区和精度问题：date 列如果是 TIMESTAMP 类型却没截断时分秒，会导致同一天多行无法聚合；或者服务器时区与业务时区不一致，让“当日”统计错位。这些细节不解决，窗口函数写得再漂亮，结果也是错的。
