SQL时间序列统计核心在于时间分组逻辑、时序连续性、业务窗口三点：需归一化时间字段对齐粒度，LEFT JOIN补全日期序列确保连续，优先用RANGE按真实时间滑动窗口，并选用timestamptz避免时区问题。
SQL时间序列统计，核心不是写多复杂的查询，而是理清“时间怎么切、数据怎么对齐、聚合怎么不漏不重”。只要抓住时间分组逻辑、时序连续性、业务窗口这三点，大部分场景都能稳住。
时间分组：别只用GROUP BY时间字段
直接按原始时间字段（比如created_at）GROUP BY，往往颗粒度太细或不对齐。比如想看“每天订单量”，但created_at是精确到秒的，得先归一化。
- 用DATE(created_at)提取日期，适用于日粒度汇总
- 用DATE_TRUNC('week', created_at)（PostgreSQL）或YEARWEEK(created_at, 1)（MySQL）对齐自然周
- 注意时区！数据库默认时区和业务时区不一致时，先AT TIME ZONE转换再截取，否则凌晨下单可能算进前一天
补全缺失日期：让图表不跳空、分析不误导
真实数据常有某天没记录，但统计报表需要连续横轴。靠LEFT JOIN生成完整日期序列最可靠。
- 用递归CTE或GENERATE_SERIES（PG）/数字表（MySQL）生成目标时间段的每日/每小时序列
- LEFT JOIN你的业务表，用COALESCE(count, 0)把NULL转成0
- 别用WHERE过滤后再JOIN——会把补的0又过滤掉，条件要写在ON里或外层处理
滚动窗口与业务周期：SUM() OVER不是万能的
计算“最近7天销量”不能只依赖ROWS BETWEEN 6 PRECEDING AND CURRENT ROW，因为原始数据未必每天都有，ROWS按行数算，容易跨过实际空白期。
- 优先用RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW（支持的数据库），按真实时间跨度滑动
- 若不支持RANGE，先补全日期序列，再用ROWS，确保每行代表一天
- 业务上“上周”“上月”这类相对周期，建议用CURRENT_DATE - INTERVAL '7 days'动态计算边界，别硬写死日期
时间类型选对，少踩80%的坑
timestamp vs timestamptz vs date —— 不是随便选的。
- timestamptz（带时区的时间戳）是线上服务首选，入库自动转UTC，查时按需转本地，避免夏令时/跨区混乱
- timestamp（无时区）存的是“本地时间字面值”，服务器换时区就错，仅适合纯本地系统
- date只存日期，做日粒度统计够用且高效；但别拿它去减时间算小时差
基本上就这些。时间序列统计不复杂，但容易忽略对齐、连续、时区这三个隐形关卡。理清楚再写SQL，比调十遍COUNT结果更省时间。
