先聊几个容易被忽视的陷阱：用 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 这类过滤条件，将脏数据阻挡在计算之外。
