窗口函数中ORDER BY非可选，必须显式声明以确保排序确定性；默认RANGE帧对重复值敏感，需用ROWS明确逐行计算；NULL在排序中默认排最前，应显式指定NULLS LAST或提前过滤。
ORDER BY 在窗口函数里不是可选的，不写可能出错
窗口函数如 ROW_NUMBER()、RANK()、SUM() OVER () 看似能不加 ORDER BY 就跑通，但实际行为极不稳定。比如 ROW_NUMBER() OVER (PARTITION BY user_id) 没写 ORDER BY，数据库会按物理存储顺序排——这个顺序不可控，不同执行、不同版本、甚至加个索引都可能让结果变。
- 显式写
ORDER BY是强制要求，尤其在需要确定性排序的场景（如分页、Top-N） - 如果业务上真不需要排序逻辑（比如只统计分区行数），用
COUNT(*) OVER (PARTITION BY ...)更安全，它不依赖排序 - PostgreSQL 会直接报错；MySQL 8.0+ 和 SQL Server 虽允许省略，但结果不可重现
SELECT user_id, amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
FROM orders;NULL 值在 ORDER BY 中默认排最前，影响排名逻辑
窗口函数的 ORDER BY 子句里，NULL 默认被当作最小值处理（即 NULLS FIRST），这和很多应用层预期相反——比如按时间排序时，created_at IS NULL 的记录会排在最上面，导致 ROW_NUMBER() 把脏数据标成“第一条”。
- 显式声明
NULLS LAST（PostgreSQL/Oracle）或等效写法（MySQL 用IS NULL判断，SQL Server 用OFFSET+FETCH配合过滤） - 若业务上
NULL表示无效数据，建议提前在WHERE过滤，别让它进窗口计算 -
RANK()和DENSE_RANK()对NULL的处理和排序一致，但相同NULL值会被视为“并列”，容易误判去重效果
错误写法：ORDER BY updated_at → NULL 排第一
正确写法：ORDER BY updated_at DESC NULLS LAST
PARTITION BY 和 GROUP BY 混用时，聚合结果易被误解
有人想“先分组统计，再对每组做累计”，于是写 SELECT ..., SUM(amount) OVER (PARTITION BY category ORDER BY date) FROM (SELECT ... GROUP BY ...) ——但子查询里用了 GROUP BY，外层窗口看到的已是聚合后的一行一行，SUM() OVER 就变成对单行重复累加，毫无意义。
- 窗口函数必须作用于明细数据（未聚合的原始行或保留明细维度的中间结果）
- 如果需要“每类累计”，直接在明细表上开窗；如果需要“每类汇总后再跨类排序”，得用两层窗口或 CTE 拆开
- 常见翻车点：把
COUNT(DISTINCT user_id) OVER (...)当成有效写法 —— 多数数据库不支持DISTINCT和窗口组合，会报错或静默忽略
可行结构：
WITH daily_orders AS (
SELECT category, date, SUM(amount) AS day_total
FROM orders GROUP BY category, date
)
SELECT *,
SUM(day_total) OVER (PARTITION BY category ORDER BY date) AS cumsum
FROM daily_orders;帧子句（ROWS/RANGE）不写默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，但 RANGE 对重复值敏感
很多用户以为 SUM(amount) OVER (ORDER BY date) 就是“到当前行为止的累计”，实际上默认是 RANGE 模式，遇到相同 date 值会把所有同日期行全算进来，导致累计值突变——比如三天数据，其中两天日期相同，第三天的累计会包含前两天全部，而非逐行推进。
- 明确需要逐行累加，必须写
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW -
ROWS按物理行序，RANGE按排序值逻辑区间，二者语义完全不同 - 性能上
ROWS通常更快，RANGE可能触发全扫描（尤其排序键有大量重复时）
典型陷阱：
-- 看似正常，但 date 相同时会把所有同日记录一起累加 SUM(sales) OVER (ORDER BY date) <p>-- 真正按行推进的写法 SUM(sales) OVER (ORDER BY date, id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
窗口函数的坑不在语法难，而在默认行为太“聪明”——自动补 RANGE、容忍无序、悄悄吞 NULL。这些设计本为简化常见场景，但一旦数据稍复杂，就变成隐性故障源。写的时候多看一眼执行计划里的 window node，比读十遍文档管用。
