必须显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，否则语义不明确；PARTITION BY须置于ORDER BY前；ORDER BY字段重复时需加唯一列保障稳定性；索引应覆盖PARTITION BY和ORDER BY字段。
SQL窗口函数中SUM() OVER(ORDER BY ...)的正确写法
直接说结论：必须显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，否则在部分数据库（如PostgreSQL 12+、SQL Server）中虽能运行，但语义不明确，MySQL 8.0+则默认采用该范围——但依赖默认行为极易出错。
常见错误是只写SUM(amount) OVER (ORDER BY date)，以为天然就是“到当前行为止的累计和”，实际上标准SQL要求明确定义窗口帧（frame），否则结果可能因引擎版本或配置而异。
-
SUM(amount) OVER (ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)是跨数据库最稳妥的写法 - 省略
ROWS ...时，PostgreSQL 默认用RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，若date有重复值，会把同日期所有行一起计入当前累计值——这不是你想要的“逐行累加” - MySQL 8.0+ 对
ORDER BY后无ROWS的情况，默认按ROWS语义处理，但文档明确建议显式写出，避免误解
分组内计算运行总和：PARTITION BY不能漏
如果要按用户、月份或类别分别算累计值，PARTITION BY必须出现在OVER子句中，且必须放在ORDER BY之前。顺序错了会报错或逻辑错乱。
典型错误示例：SUM(sales) OVER (ORDER BY day PARTITION BY region) —— 语法非法，PARTITION BY必须前置。
- 正确写法：
SUM(sales) OVER (PARTITION BY region ORDER BY day ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) - 分区字段值相同时，窗口只在该分区内独立排序并累计；跨分区不混算
- 若漏掉
PARTITION BY，整个结果集被当作一个大组处理，所有行按ORDER BY排完再累计，失去分组意义
ORDER BY字段重复时的陷阱：用唯一键补足排序稳定性
当ORDER BY字段存在重复（比如多个订单同一天），不同数据库对“当前行”的界定可能不一致，导致累计值跳变或重复累加。
例如：两笔金额为100和200的订单都在2024-01-01，仅按ORDER BY order_date，数据库无法保证哪一笔先算进累计——SUM()结果可能不稳定。
- 解决方法：在
ORDER BY中加入唯一列，如ORDER BY order_date, order_id - 即使业务上不关心顺序，也应补上主键或时间戳微秒字段，确保窗口帧边界可预测
- 不要依赖“插入顺序”或“物理存储顺序”，SQL标准不保证这些
性能提示：索引对窗口函数执行效率的影响
窗口函数本身不走索引，但ORDER BY字段若有对应索引，能显著加快排序阶段——尤其在大数据量分组累计场景下。
- 推荐为常用窗口排序字段建复合索引，例如：
CREATE INDEX idx_region_day ON sales(region, day); - 注意：
PARTITION BY字段必须是索引前导列，否则索引可能失效 - 在PostgreSQL中，若
ORDER BY含表达式（如DATE(created_at)），需建函数索引才能生效
窗口帧定义看着只是语法细节，但一旦涉及分组+重复值+大数据量，没写清楚ROWS或没对齐排序稳定性，结果就可能线上跑偏——这种问题往往上线后才暴露，查起来特别费劲。
