SQL窗口函数实战：避开这三个坑，让你的累计计算又快又准
窗口函数是数据分析的利器，尤其是做累计计算时。但你知道吗？有些细节没处理好，结果可能南辕北辙，甚至性能直接崩掉。今天咱们就聊聊几个最容易踩坑的地方。
窗口函数里 ORDER BY 必须写，否则累计值全错
你是不是也以为，SUM() OVER (PARTITION BY ...) 不加 ORDER BY 也能凑合用？这里有个大坑：不加 ORDER BY，数据库会按“未定义顺序”累加。这个“未定义”可不是随机，而是完全依赖查询计划和数据的物理存储顺序。后果就是，同一句SQL，今天跑和明天跑，结果可能不一样。
经常遇到的现象是：amount 字段看起来明明有序，但生成的累计列却出现跳变或者重复累加。更头疼的是，测试环境数据量小的时候一切正常，一上线数据量大了，问题就全暴露了。
- 所以，
ORDER BY必须明确指定排序依据，通常是时间字段（比如created_at）或者业务流水号（比如seq_no）。 - 如果业务上允许同一排序值有多行数据（比如同一秒内有多笔交易），那就需要再加一个唯一键来兜底，例如写成
ORDER BY created_at, id。 - 这一点在主流数据库里都是硬性要求，无论是 MySQL 8.0+、PostgreSQL、SQL Server，还是 SQLite 3.25+，想要正确的累计逻辑，就必须显式写上
ORDER BY。
多个维度分组 + 多个方向累计，得用多个 WINDOW 子句
业务需求复杂起来，经常需要同时计算多个维度的累计值。比如，既要看“按用户累计的总金额”，又要看“按用户+月份累计的金额”。这时候可别想着用嵌套 OVER 子句，代码会立刻变得难以阅读且极易出错。
这种需求在报表里很常见：既要观察个人的长期趋势，又要分析当月内的每日进展，两个累计逻辑必须并存。
- 正确的做法是使用命名的
WINDOW子句。先定义：WINDOW w1 AS (PARTITION BY user_id ORDER BY created_at)，这是用户级别的窗口。 - 再定义：
WINDOW w2 AS (PARTITION BY user_id, DATE(created_at) ORDER BY created_at)，这是按天粒度的窗口。 - 然后在 SELECT 列表里直接引用：
SUM(amount) OVER w1和SUM(amount) OVER w2。这样既避免了重复书写冗长的表达式，结构也清晰。 - PostgreSQL 对此语法支持良好；MySQL 8.0.2+ 和 SQL Server 2022 也跟进了。如果是旧版 MySQL，那就只能重复写完整的
OVER子句了，但务必反复核对括号和逗号的位置。
累计值需要去重求和？别在窗口里 DISTINCT
想计算“每个用户下不重复订单金额的累计”？直接把聚合函数的习惯带过来，写成 SUM(DISTINCT amount) OVER (...)？抱歉，这条路走不通。所有主流数据库都不支持在窗口函数内使用 DISTINCT。
常见的报错是这样的：ERROR 3586 (HY000): Window function 'sum' with DISTINCT is not allowed（MySQL），其他数据库也会有类似的提示。
- 解决方案是换一个思路，把去重步骤提前。可以先用子查询或者 CTE（公共表表达式），按
user_id, order_id把重复记录去重，然后再对这个中间结果应用窗口函数进行累计。 - 另一个技巧是使用
ROW_NUMBER()标记：ROW_NUMBER() OVER (PARTITION BY user_id, order_id ORDER BY created_at) AS rn，然后在外层查询中过滤rn = 1的记录，再进行累计求和。 - 记住一个原则：
DISTINCT可以在窗口函数之外使用，但它会改变分组结构。核心是要保证去重操作发生在窗口计算之前。
性能敏感时，慎用 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
窗口函数的默认框架是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，这个通常是安全的。但如果你显式地写成 RANGE 模式，并且在排序字段存在重复值时，就可能引发性能灾难，慢到查询超时。
什么情况下会想用 RANGE 呢？通常是按数值范围进行累计，比如“计算小于等于当前金额的所有记录之和”。这时候很容易误用。
- 关键在于，只要排序字段有重复值，
RANGE就会把所有具有相同排序值的行，都纳入当前行的窗口范围。这会导致窗口逻辑上的数据量急剧膨胀，计算开销大增。 - 事实上，99% 的业务累计需求，使用
ROWS模式就完全足够了，而且性能稳定可预测。只有极少数特定的分析场景（如计算移动百分位数）才真正需要RANGE。 - 另外，在 PostgreSQL 中，
RANGE对于TIMESTAMP类型默认按微秒精度对齐。如果你的时间字段精度只到秒，可能会意外地把多行数据合并到同一个窗口里，导致计算结果不符合预期。
总结一下，窗口函数的语法看似简单，但 ORDER BY 的语义、去重的时机、RANGE 与 ROWS 的行为差异，这几个因素叠加在一起，很容易在数据量小的时候隐藏问题，等到数据量上来了才一起爆发。千万别等到上线后，被运营同事追着修改日报逻辑时才后悔莫及。
