时间序列统计在业务SQL里出现频率很高，但真正能稳定输出可用结果的写法并不多。如果只对日期做简单分组，遇到没有订单的日期就会丢点；如果直接用子查询反复扫描整表，数据量上去后查询会明显变慢。处理时间序列的核心思路可以拆成三块：先构造连续时间轴，再用窗口函数做跨行计算，最后通过日期轴回填缺失值。这样能把统计逻辑留在数据库内部完成，减少导出到脚本再加工的环节。

一、构造连续日期轴是后续统计的基础

业务明细表里通常只会保存实际发生的数据，某一天没有订单，表中就没有对应行。直接对日期做分组统计，结果天然就是不连续的。这种不连续在报表里表现为折线图断裂，在移动平均计算中会导致窗口范围出错。例如要计算最近7天的平均值，如果中间少了两天，窗口实际上覆盖了9个自然日，统计口径就完全变了。因此时间序列统计的第一步不是马上聚合，而是先保证日期本身是连续、完整的。

构造连续日期轴有两种常用方式。第一种是物理日期维度表，提前生成未来若干年的每一天，并附带周、月、季度、节假日等字段。这种表维护成本低，查询速度快，适合生产环境长期使用。第二种是使用递归CTE动态生成指定范围的日期序列，适合临时分析或没有权限建表的场景。以MySQL 8为例，可以这样生成从指定开始日期到结束日期的连续日序：

WITH RECURSIVE date_axis AS (
  SELECT CAST('2024-01-01' AS DATE) AS dt
  UNION ALL
  SELECT DATE_ADD(dt, INTERVAL 1 DAY)
  FROM date_axis
  WHERE dt < CAST('2024-01-31' AS DATE)
)
SELECT dt FROM date_axis;

递归CTE会先取出行`2024-01-01`，然后每次加一天，直到满足终止条件。这个写法在PostgreSQL、SQL Server中稍作调整也能使用。需要注意，MySQL默认递归深度限制为1000，如果日期跨度较长，要适当调整会话参数，或者改用物理日期维度表。日期轴独立于业务表存在，后续做左连接时，没有业务数据的日期就能自然保留下来。

生产环境中更推荐使用物理日期维度表。它不依赖递归语法，迁移成本低，还可以存下星期、是否工作日、是否节假日等业务属性。比如分析工作日和周末的流量差异时，不需要在查询里反复计算星期，直接关联维度表字段就能过滤。日期轴和业务表分离后，时间序列统计的可维护性会明显提升。

二、窗口函数完成滚动统计与同比环比

普通聚合函数会把一组多行压缩成单个结果，窗口函数则能在保留原始行的同时进行跨行计算。在时间序列场景中，最常用的窗口函数是`SUM`、`AVG`配合`OVER`子句。`ORDER BY`用来指定按时间顺序移动，`ROWS BETWEEN ... AND ...`用来界定窗口帧范围。计算累计值、当日总值、近7日移动平均，都可以在同一个查询里完成。

假设已经有一张按日汇总过的订单表`daily_orders`，包含`order_date`和`amount`两个字段。下面代码同时计算累计销售额、近7日销售额总和以及近7日平均销售额：

SELECT
  order_date,
  amount,
  SUM(amount) OVER (ORDER BY order_date) AS cumulative_sum,
  SUM(amount) OVER (
    ORDER BY order_date
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  ) AS rolling_7d_sum,
  AVG(amount) OVER (
    ORDER BY order_date
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  ) AS rolling_7d_avg
FROM daily_orders
ORDER BY order_date;

`ROWS BETWEEN 6 PRECEDING AND CURRENT ROW`表示从当前行往前6行，再加上当前行，一共7行数据。如果前面的行数不足6行，窗口会自动缩小到可用的范围，不会报错。这里的核心优势是不需要为每一个日期单独发一条子查询，数据库在扫描一次数据后就能完成全部窗口计算，效率比多次自连接高很多。

同比和环比同样是时间序列统计中的高频需求。环比通常指与上一个周期对比，比如今天的销售额和昨天比；同比通常指与去年相同日期比。使用`LAG`函数可以取到前面第N行的值，再与当前行做运算。例如计算日环比增长率：

SELECT
  order_date,
  amount,
  LAG(amount, 1) OVER (ORDER BY order_date) AS prev_day_amount,
  ROUND(
    (amount - LAG(amount, 1) OVER (ORDER BY order_date)) * 100.0 /
    NULLIF(LAG(amount, 1) OVER (ORDER BY order_date), 0),
    2
  ) AS day_over_day_pct
FROM daily_orders
ORDER BY order_date;

这里用`NULLIF`把除数转换成NULL，可以避免前一天金额为0时出现除零错误。窗口函数中的`LAG`多次出现虽然看起来重复，但在MySQL中通常可以被优化器识别，不会造成明显的性能负担。不同数据库的方言略有差异，但核心逻辑一致。需要注意，如果日期轴不连续，`LAG`拿到的是表中的前一行，而不是自然日的前一天。因此做环比前，最好先让日期连续，否则结果可能被错误解读。

三、回填缺失日期与性能优化

有了连续日期轴和窗口函数，接下来要把两部分组合起来。用日期轴左连接业务汇总表，业务表没有数据的日期，金额字段会是NULL。为了让后续窗口计算能够正确处理，需要用`COALESCE`把NULL转换为0。这样日期轴上的每一天都有行，移动平均和累计值才会按自然日计算。

WITH RECURSIVE date_axis AS (
  SELECT CAST('2024-01-01' AS DATE) AS dt
  UNION ALL
  SELECT DATE_ADD(dt, INTERVAL 1 DAY)
  FROM date_axis
  WHERE dt < CAST('2024-01-31' AS DATE)
)
SELECT
  a.dt,
  COALESCE(d.amount, 0) AS amount,
  SUM(COALESCE(d.amount, 0)) OVER (
    ORDER BY a.dt
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  ) AS rolling_7d_sum
FROM date_axis a
LEFT JOIN daily_orders d ON d.order_date = a.dt
ORDER BY a.dt;

这段查询的关键在于连接条件必须放在`ON`子句中，不能用`WHERE`过滤日期轴。否则又会把没有业务数据的日期丢掉。如果业务表是按小时或分钟记录的，应该先在子查询里聚合到日粒度，再与日期轴连接。直接在明细级别做窗口计算，窗口帧可能需要扫描大量无用的行，性能会急剧下降。

性能优化方面，最有效的是给日期字段建立索引。对`daily_orders`表的`order_date`建普通B树索引，可以加快连接和排序。如果数据量达到千万级，建议按日期做范围分区，让查询只扫描相关分区。窗口函数虽然没有传统子查询那么多重复扫描，但仍然会消耗内存进行排序，所以尽量把参与窗口计算的列控制在最小值。对于每天只需要相对固定汇总结果的场景，可以考虑定时生成结果表或物化视图，前端报表直接读结果，避免实时计算大窗口。

时间序列统计并不神秘，重点就是连续日期轴、窗口帧计算和缺失值回填这三件事。把统计口径固定在SQL内部，既能让结果稳定一致，也能减少不同工具之间来回搬运数据的成本。实际业务中可以先从日粒度入手，再逐步扩展到周、月、小时粒度，形成一套可复用的时间序列查询模板。