sum() over不能直接做fifo库存消减，因其仅支持累计求和，缺乏“剩余量传递”“跨行状态更新”等能力；fifo本质是逐行状态传递问题，需递归cte、变量或应用层实现。
为什么SUM() OVER不能直接做FIFO库存消减
SUM() OVER 是累计求和，它按指定顺序把前面所有行的值加起来，但库存FIFO消减的核心是：每一笔出库要“抵扣”最早入库的未消耗数量，可能跨多条入库记录，且每条入库可能只被部分消耗。这本质上是**逐行状态传递**问题，不是简单累加——SUM() OVER 没有“剩余量”“已用完”“跳到下一条”这类状态控制能力。
用窗口函数模拟FIFO必须配合递归或自连接
真正在SQL里做FIFO库存消减，常见可靠做法是先生成“入库-出库”时间线，再用递归CTE（PostgreSQL/SQL Server）或变量（MySQL 8.0+）逐行计算剩余可用量。比如在PostgreSQL中：
WITH RECURSIVE fifo AS (
SELECT
id, qty_in, qty_out, ts,
LEAST(qty_in, qty_out) AS consumed,
GREATEST(0, qty_out - qty_in) AS remaining_out,
ROW_NUMBER() OVER (ORDER BY ts) AS rn
FROM inventory_events
WHERE rn = 1
UNION ALL
SELECT
e.id, e.qty_in, f.remaining_out,
LEAST(e.qty_in, f.remaining_out),
GREATEST(0, f.remaining_out - e.qty_in),
e.rn
FROM inventory_events e
INNER JOIN fifo f ON e.rn = f.rn + 1
)
SELECT * FROM fifo;
关键点：remaining_out 是上一轮没消完的出库量，必须显式传递；LEAST 和 GREATEST 控制单次抵扣上限；没有递归，就无法让第3条入库知道前2条是否已被用完。
用SUM() OVER强行“近似”FIFO的适用场景和风险
只有当业务允许“按时间累计入库量 ≥ 累计出库量”的粗略判断时，才能用 SUM() OVER 做辅助判断，例如查“哪天开始库存转负”：
SELECT *, SUM(qty_in) OVER (ORDER BY ts) - SUM(qty_out) OVER (ORDER BY ts) AS net_stock FROM inventory_events;
但这不是真实FIFO消减结果——它不告诉你第5笔出库到底消耗了第1、2、3笔中的多少，只给一个全局累计差值。容易踩的坑包括：
-
ORDER BY ts必须严格保证入库/出库混排时的时间精度（毫秒级），否则同秒事件顺序不确定 - 如果存在“先出后入”逻辑（如退货冲回），
SUM() OVER会彻底失效 - 无法支撑“查询某笔入库还剩多少未消耗”这类需求
真正需要FIFO结果时，优先考虑应用层计算
数据库做FIFO消减性能差、逻辑难维护，尤其是数据量大或并发更新频繁时。更务实的做法是：
- 入库/出库操作由应用层按时间戳排序后，用循环+状态变量实时计算每笔消耗来源
- 数据库只存原始流水，FIFO结果作为物化视图或缓存字段定期更新（比如每小时跑一次）
- 用专用库存引擎（如Redis Sorted Set按时间戳存入库批次，pop时按score从小到大取）
FIFO的本质是带状态的流式处理，SQL的声明式语法天然不适合——别硬套 SUM() OVER，该交出去的就交出去。
