SQL时间序列统计需聚焦时间对齐、窗口连续性控制和性能优化：用GENERATE_SERIES补零确保时段完整；ORDER BY加主键防窗口错位，优先用RANGE按自然日滚动；建联合索引、分区表并避免时间字段函数化以提升查询效率。
SQL时间序列统计的核心是把时间当维度来分组、对齐和聚合，不是简单加个ORDER BY time就完事。关键在三点：时间对齐（比如按小时/天补0）、窗口连续性控制（避免跨天混算）、以及减少全表扫描（用好索引和分区）。下面从实操角度拆解常见卡点和优化动作。
时间对齐：别让空档期“消失”
原始数据常有缺失（比如某小时没记录），直接GROUP BY DATE_TRUNC('hour', ts)会跳过这些时段，导致趋势图断层。需要主动补全时间点：
- 用
GENERATE_SERIES（PostgreSQL）或递归CTE（MySQL 8.0+/SQL Server）生成完整时间轴 - 再LEFT JOIN原始数据，配合
COALESCE(count, 0)填零 - 示例：统计2024-01-01每小时订单量，即使某小时为0也要显示
窗口计算：明确边界，别被“自动滚动”坑了
用ROW_NUMBER()、LAG()或AVG() OVER (ORDER BY ts ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)时，必须确认排序字段唯一且无重复时间戳。否则同一秒多条记录会导致窗口错位。
- 建议在ORDER BY里加主键或自增ID做二级排序：
ORDER BY ts, id - 若需严格按自然日滚动（如“最近7天”），用
RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW比ROWS更稳妥 - 注意：MySQL旧版本不支持RANGE带INTERVAL，得用子查询+DATE_SUB模拟
性能优化：让数据库少翻“旧账”
时间序列查询慢，90%是因为扫了太多历史分区或没走索引。
- 给时间字段建索引——但别只建单列索引；高频查“某用户+某时间段”就建联合索引
(user_id, created_at) - 按月/周分区表（如
PARTITION BY RANGE (TO_DAYS(created_at))），查询时数据库能自动裁剪无关分区 - 避免在WHERE里对时间字段用函数：
WHERE YEAR(created_at) = 2024会让索引失效；改成WHERE created_at >= '2024-01-01' AND created_at
聚合预计算：高频统计别每次都算
如果“每小时UV”“每日留存率”这类指标被多个报表反复调用，实时算成本高又拖慢响应。
- 用物化视图（PostgreSQL）或汇总表（MySQL）定期固化结果，比如每小时跑一次任务写入
hourly_stats表 - 查最新统计时优先查汇总表，只对“刚过去10分钟”的数据走实时计算作补充
- 加个
last_updated字段标记汇总时效，应用层可据此决定是否接受缓存结果
基本上就这些。时间序列不是语法难题，而是设计思维——想清楚“时间怎么切、空档怎么填、边界怎么控、历史怎么减”，SQL自然就快而稳。
