sql时间序列统计的核心是理清“时间切片”与业务逻辑的对应关系，需显式归一周期锚点、补全日期序列、用窗口函数处理滚动计算，并统一时区转换。
SQL时间序列统计的核心，不是堆函数，而是理清“时间切片”和“业务逻辑”的对应关系。真实场景里，数据往往不规整、缺失、跨时区、或需滚动计算——这时候，光靠 GROUP BY + date() 往往失效。
按自然周期对齐：别直接 trunc，先确认业务定义
比如“统计每周销量”，业务上可能要求“周一到周日为一周”，但数据库里 DATETRUNC(‘week’, order_time) 在不同数据库默认起点不同（postgresql 从周日开始，Snowflake 可设）。更稳妥的做法是显式归一：
- 用 order_time::date – EXTRACT(dow FROM order_time)::int + 1 算出当周周一日期（PostgreSQL）
- mysql 可用 DATE_SUB(order_time, INTERVAL WEEKDAY(order_time) DAY)
- 关键点：把原始时间转成“周期锚点”，再 GROUP BY 这个锚点，而非依赖内置 trunc 行为
处理时间断点与空值：用生成日期序列补全
销售报表常要“连续展示近30天，哪怕某天没订单也显示0”。这时不能只查 orders 表，得主动构造时间轴：
- 用递归 CTE 或 generate_series（PostgreSQL）/ numbers table（MySQL）生成目标日期列表
- LEFT JOIN 订单表，再用 COALESCE(count, 0) 填补空缺
- 示例片段（PostgreSQL）：WITH days AS (select current_date – n AS dt FROM generate_series(0,29) n) SELECT d.dt, COALESCE(SUM(o.amount), 0) FROM days d LEFT JOIN orders o ON d.dt = o.order_date GROUP BY d.dt ORDER BY d.dt;
滚动窗口与同比环比：窗口函数比子查询更稳
算“近7日平均销量”或“较上周同期增长”，容易陷入多层嵌套子查询，既慢又难维护。直接用窗口函数更清晰：
- 滚动7日均值：AVG(amount) OVER (ORDER BY order_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)
- 同比（上年同日）：LAG(amount, 365) OVER (ORDER BY order_date)
- 注意：LAG/LEAD 默认按 ORDER BY 排序，若存在同天多条记录，需先按天聚合，再开窗，否则会错位
时区与本地时间混用：统一转换，不在 WHERE 里硬写 +8
用户下单时间存 UTC，但运营要看“北京时间当日销量”。错误做法：WHERE order_time + INTERVAL ‘8 HOURS’ >= ‘2024-06-01’。问题在于索引失效、跨夏令时风险。
- 正确方式：建表达式索引 CREATE INDEX idx_order_date_bj ON orders ((order_time AT TIME ZONE ‘Asia/Shanghai‘))
- 查询时用 (order_time AT TIME ZONE ‘Asia/Shanghai’)::date = ‘2024-06-01’
- 所有时间过滤、分组、展示，都基于明确的时区转换结果，而不是在字段上加减数字
基本上就这些。时间序列统计真正卡人的，从来不是语法，而是对“时间如何承载业务含义”的理解。多问一句“这个‘周’是谁定义的？”“这天没数据，是真没有，还是没录进系统？”，比背十个开窗函数更有用。