用 sum() over(order by 入库时间, id) 计算累计入库量，需确保排序字段唯一稳定；漏写 order by 会导致全表求和，where 过滤后累计重置；多记录时间相同时须加 id 避免平台跳变；索引应匹配排序字段如 (入库时间, id) 或 (仓库id, 入库时间, id)。
用 SUM() OVER() 计算按时间排序的累计入库量
库存累计入库量本质是「按入库时间顺序，把每笔入库数量逐行累加」，直接用 SUM() OVER (ORDER BY 入库时间) 就能解决。关键不是函数本身，而是排序字段必须能唯一、稳定地反映业务先后——比如用 入库时间，但若存在秒级相同的时间戳，就得补上主键或自增 ID 避免窗口排序歧义。
常见错误是漏写 ORDER BY：没有它，SUM() OVER() 会默认对整个分区（或全表）求和，结果每行都一样，不是“累计”。另外，别在 WHERE 中过滤掉早期记录后还指望累计值连续——窗口函数在 WHERE 之后执行，被过滤掉的行不参与计算，累计会从第一条保留记录开始重新累加。
- 推荐排序组合：
ORDER BY 入库时间, id（id是自增主键） - 避免用
ORDER BY 入库时间 DESC——这会倒着累计，不符合“随时间增长”的业务理解 - 如果数据来自多仓库，需加
PARTITION BY 仓库ID防止跨仓混加
处理同一时间多笔入库时的累计值重复问题
当多条入库记录 入库时间 完全相同时，SUM() OVER(ORDER BY 入库时间) 会把这批记录视为“同序”，它们共享同一个累计值（即这批记录的总和加到前序累计值上），导致中间出现平台跳变，而非逐行递增。这不是 bug，是 SQL 窗口排序的确定性行为。
真实业务中，你往往希望“哪怕时间相同，也按录入顺序一条条累加”。这时必须引入更细粒度的排序依据：
- 优先用数据库自增
id或业务单据号（如receipt_no）补充排序：ORDER BY 入库时间, id - 若无可靠序号，可加
ROW_NUMBER() OVER (ORDER BY 入库时间, id) AS rn辅助列再排序，但会多一次计算 - 不建议用
ORDER BY 入库时间, RANDOM()——破坏结果可重现性，调试和核对困难
与普通 SUM(GROUP BY) 的区别和误用场景
SUM() OVER() 是逐行输出，每行带当前累计值；而 SUM() GROUP BY 是聚合后只返回一行/组。有人想“先按天汇总入库量，再算天级累计”，就错写成：
SELECT SUM(数量) AS 日入库, SUM(SUM(数量)) OVER (ORDER BY 日期) FROM t GROUP BY 日期
这语法合法但逻辑危险：外层 SUM(SUM()) 在窗口里叠加的是已聚合的每日总量，看似合理，实则丢失了原始明细粒度。一旦某天有退货冲红、或需要关联其他明细字段（如供应商、批次），这种写法立刻失效。
- 正确做法：先保持明细行，用
SUM(数量) OVER (ORDER BY 入库时间, id)得到每笔入库后的实时库存水位 - 如真需日级累计，应在明细层加
DATE(入库时间)列，再PARTITION BY DATE(入库时间) ORDER BY 入库时间, id，而非先GROUP BY - 注意：MySQL 8.0+、PostgreSQL、SQL Server、Oracle 均支持；SQLite 3.25+ 支持，旧版不支持
性能敏感点：索引怎么建才让累计计算不慢
窗口函数本身不走索引，但 ORDER BY 字段的排序效率直接受索引影响。特别是数据量大（百万级以上）、又频繁查“截至某时间的累计量”时，没索引会导致每次全表扫描+排序。
- 必须为
ORDER BY中的字段建联合索引，顺序严格匹配：例如用ORDER BY 入库时间, id，就建INDEX idx_in_time_id ON 表名(入库时间, id) - 不要只建
(入库时间)单列索引——数据库可能仍需回表排序id，尤其当id不是聚簇索引时 - 如果查询常带
WHERE 仓库ID = ?，索引应扩展为(仓库ID, 入库时间, id)，兼顾过滤与排序
累计值本身无法预存（除非用物化视图或应用层缓存），所以索引是提升响应速度最实际的手段。别寄希望于“加个 WHERE 入库时间 就能自动剪枝”——窗口函数的 <code>ORDER BY 范围仍是全量满足 WHERE 的结果集，排序开销不会因 WHERE 条件变小而线性下降。
