SQL Server窗口函数计算年度累计销售额完整实现方法

先聊几个容易被忽视的陷阱：用 SUM() OVER() 计算年度累计销售额，本身并不复杂，但要想准确无误，有几个关键点必须牢牢把握——分区、排序、日期范围，任何一环出了差错，结果都会偏离预期，并且往往不会立即被发现。

窗口函数的 PARTITION BY 和 ORDER BY 如何搭配？

年度累计，并不是简单地对整张表逐行累加，而是需要按年份分组，在每个分组内按照时间顺序逐月（或逐日）进行累加。因此，PARTITION BY YEAR(sale_date) 是必备条件，ORDER BY sale_date 则决定了累加的顺序。如果 ORDER BY 字段写错，比如使用了 product_id，或者干脆遗漏了该子句，累计值就会变成无序的、零散的数值组合，完全失去时间维度的意义。

常见的错误包括：

• 遗漏年份分区：如果只写 ORDER BY sale_date 而忘记 PARTITION BY YEAR(sale_date)，就会导致跨年累加的错误——比如将 2023 年 12 月的销售额与 2024 年 1 月的销售额合并在一起。
• 排序字段选择不当：用 ORDER BY amount 进行排序，会使销量高的月份优先累加，完全打乱时间线的逻辑。
• 日期字段类型不规范：日期字段必须为 DATE 或 DATETIME 类型，不能使用字符串存储。否则，调用 YEAR() 函数时要么提取出错，要么触发隐式转换失败，结果一片混乱。

如何处理同一天的多笔订单？

在实际业务中，同一天内产生多笔订单是常态。如果直接对原始明细行执行 SUM(amount) OVER(...)，累计值就会重复计算——同一日期的多笔订单会被当作多条记录逐行累加，结果显然有误。正确的做法是：先按日进行聚合，然后在聚合后的结果集上应用窗口函数。

SELECT   sale_date,  daily_total,  SUM(daily_total) OVER (    PARTITION BY YEAR(sale_date)     ORDER BY sale_date  ) AS cum_sumFROM (  SELECT     CAST(sale_time AS DATE) AS sale_date,    SUM(amount) AS daily_total  FROM sales  GROUP BY CAST(sale_time AS DATE)) t

这里有一个细节：CAST(sale_time AS DATE) 比使用 CONVERT(VARCHAR(7), sale_time, 120) 转换为字符串更可靠——后者容易陷入字符串比较的陷阱，导致排序逻辑混乱。

为什么使用 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW？

严格来说，这是 SQL Server 默认的窗口帧行为，但显式地写出来不仅更安全，也能让代码意图更清晰。默认情况下，窗口帧就是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，即从当前年份的第一行一直累加到当前行。如果错误地使用 RANGE（尤其在日期存在重复值的情况下），累计值可能会因为隐式的去重逻辑而在某个日期第一次出现时“跳跃”，结果与预期大相径庭。

• ROWS 模式：严格按物理行的位置进行累加，稳定可靠。
• RANGE 模式：会将相同 sale_date 的所有行视为一组，累计值只在组内第一行发生时跳变，容易导致数据断层。
• 另外，不要省略帧定义——虽然默认值存在，但不同 SQL Server 版本或兼容性级别下，默认行为可能存在细微差异，显式写出是消除歧义的最直接方式。

最后，也是最容易被忽略的一步：数据清洗。销售日期字段中很可能混入 NULL 或非法日期，比如 '9999-01-01'。这类脏数据一旦被 YEAR() 函数识别，会返回 NULL，导致整年数据被归入同一个分区，累计逻辑彻底失效。因此，上线前务必添加 WHERE sale_date IS NOT NULL AND ISDATE(sale_date) = 1 这类过滤条件，将脏数据阻挡在计算之外。