库存快照报表升级实战：SQL 窗口函数 + 分区管理（MySQL 8.0）

前言: 针对需求的迭代升级，报表侧需要做最新值、波动、TopN、趋势分析等展示，以便业务侧检测，考虑了通用性以及性能等方面，决定不在java服务层去实现这个需求升级，采用SQL窗口函数的方式来解决，正好复盘总结下。

库存快照报表升级实战：SQL 窗口函数 + 分区管理（MySQL 8.0）

适合读者：做库存、订单、对账、报表系统的后端/数据开发同学

文章目标：讲清楚 SQL 窗口函数在库存快照场景里 是什么、为什么、怎么用

一、为什么很多库存报表"能跑但不好用"？

在库存系统里，常见链路是：

定时把 inventory 写入 inventory_snapshot
按 snapshot_time 做日分区
报表侧做最新值、波动、TopN、趋势分析

问题往往出在第 3 步：

很多团队仍用"GROUP BY + 子查询 + Java 二次处理"实现分析逻辑，结果是：

SQL 越写越长，可读性差
业务逻辑分散在服务层，不易维护
新增报表需求时改动大、回归成本高

这就是窗口函数的主场。

二、窗口函数是什么（What）

窗口函数（Window Function）是：
在保留明细行的前提下，对组内数据做统计分析。

语法骨架：

sql 复制代码

function_name(...) OVER (
  PARTITION BY ...
  ORDER BY ...
  ROWS/RANGE ...
)

三要素：

PARTITION BY：分组（但不折叠行）
ORDER BY：组内顺序
ROWS/RANGE：计算窗口范围（如累计、滑动）

三、为什么要用（Why）：和普通聚合函数的区别

对比项	普通聚合函数（GROUP BY）	窗口函数（OVER）
行数变化	多行压缩成少行	明细行保留
典型用途	汇总统计	排名、环比、累计、TopN
复杂查询表达	常需多层子查询	单条 SQL 可表达
可维护性	复杂场景下较差	业务语义更直观

一句话：
GROUP BY 负责"汇总"，窗口函数负责"分析"。

四、和分区管理怎么结合？

很多同学会问：已经做了快照分区，还需要窗口函数吗？

答案：需要，而且两者是互补关系。

分区管理解决"怎么存、怎么删、怎么控范围"
窗口函数解决"怎么算、怎么算得清楚"

在库存快照系统里，推荐组合是：

写入层：快照任务持续写 inventory_snapshot
存储层：按 snapshot_time 分区，定时维护分区
分析层：报表查询统一使用窗口函数模板

五、库存快照报表 4 个高频窗口函数模板（可直接用）

以下示例基于 inventory_snapshot（字段如 entity_id、warehouse_code、snapshot_time、able_quantity、id）。

1）批量取每个 SKU+仓的最新快照

sql 复制代码

SELECT *
FROM (
  SELECT
    s.*,
    ROW_NUMBER() OVER (
      PARTITION BY s.entity_id, s.warehouse_code
      ORDER BY s.snapshot_time DESC, s.id DESC
    ) AS rn
  FROM inventory_snapshot s
  WHERE s.snapshot_time >= #{startTime}
    AND s.snapshot_time <  #{endTime}
) t
WHERE t.rn = 1;

适用：最新库存看板、主数据回填、去重取最新。

2）环比变化：和上一条快照对比

sql 复制代码

SELECT
  s.entity_id,
  s.warehouse_code,
  s.snapshot_time,
  s.able_quantity,
  s.able_quantity - LAG(s.able_quantity, 1, s.able_quantity) OVER (
    PARTITION BY s.entity_id, s.warehouse_code
    ORDER BY s.snapshot_time, s.id
  ) AS delta_able_qty
FROM inventory_snapshot s
WHERE s.snapshot_time >= #{startTime}
  AND s.snapshot_time <  #{endTime};

适用：库存突增突降分析、波动报警解释。

3）每仓每天波动 TopN SKU

sql 复制代码

SELECT *
FROM (
  SELECT
    x.d,
    x.warehouse_code,
    x.entity_id,
    x.abs_change,
    DENSE_RANK() OVER (
      PARTITION BY x.d, x.warehouse_code
      ORDER BY x.abs_change DESC
    ) AS rk
  FROM (
    SELECT
      DATE(s.snapshot_time) AS d,
      s.warehouse_code,
      s.entity_id,
      ABS(
        s.able_quantity - LAG(s.able_quantity, 1, s.able_quantity) OVER (
          PARTITION BY s.entity_id, s.warehouse_code
          ORDER BY s.snapshot_time, s.id
        )
      ) AS abs_change
    FROM inventory_snapshot s
    WHERE s.snapshot_time >= #{startTime}
      AND s.snapshot_time <  #{endTime}
  ) x
) t
WHERE t.rk <= 10;

适用：运营巡检、仓内异常 SKU 排查。

4）累计轨迹：运行总和

sql 复制代码

SELECT
  s.inventory_id,
  s.snapshot_time,
  s.withhold_quantity,
  SUM(s.withhold_quantity) OVER (
    PARTITION BY s.inventory_id
    ORDER BY s.snapshot_time, s.id
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS running_withhold_qty
FROM inventory_snapshot s
WHERE s.inventory_id = #{inventoryId}
  AND s.snapshot_time >= #{startTime}
  AND s.snapshot_time <  #{endTime};

适用：趋势分析、复盘报告、可视化曲线数据源。

六、MyBatis 项目落地建议（实战可执行）

建议在 Mapper 中固定 3 类方法：

findLatestSnapshotBatch
querySnapshotDeltaTrend
queryWarehouseDailyTopFluctuation

服务层只做参数编排，不做复杂计算。

这样可以把"分析能力"沉淀在 SQL 层，避免 Java 侧重复实现。

七、性能与稳定性注意点（重点）

强制时间范围过滤 ：snapshot_time >= ? AND snapshot_time < ?
- 这是分区裁剪生效的关键
窗口排序要稳定 ：建议 ORDER BY snapshot_time, id
索引建议
- (entity_id, warehouse_code, snapshot_time, id)
- (inventory_id, snapshot_time, id)
先过滤再开窗：减少窗口计算数据量
上线前做 EXPLAIN：重点看排序和临时表开销

八、版本兼容：MySQL 哪些版本可用？

✅ MySQL 8.0+：支持窗口函数
❌ MySQL 5.7 及以下：不支持 ROW_NUMBER/LAG/DENSE_RANK

建议先执行：

sql 复制代码

SELECT VERSION();

九、结论

库存快照系统要做得"既稳又强"，核心是两层升级：

分区管理：保证数据生命周期治理和查询范围控制
窗口函数：提升报表分析表达力和可维护性

把这两者结合后，报表开发会从"功能可用"升级到"分析可复用"，这是库存系统从工程化走向数据化的关键一步。

十、可直接复用的检查清单

快照表是否按时间分区
报表 SQL 是否统一带时间范围
是否有"最新值/环比/TopN/累计"窗口函数模板
是否把复杂计算留在 SQL，而不是散在 Java 层
是否用 EXPLAIN 验证窗口查询性能

复制代码

库存快照报表升级实战：SQL 窗口函数 + 分区管理（MySQL 8.0）