会出错且结果不可预测：不加ORDER BY时，ROW_NUMBER()等窗口函数行为未定义，分组内排名失效，累计求和变分组总和，移动平均帧定位漂移；NULL需用COALESCE处理；排名选型依并列需求而定。
窗口函数里 ORDER BY 忘加会出错吗？
会，而且结果完全不可预测——ROW_NUMBER()、SUM() OVER()、AVG() OVER() 这些函数在没写 ORDER BY 时，SQL 标准允许数据库按任意顺序处理行，PostgreSQL 可能返回稳定结果，MySQL 8.0+ 和 SQL Server 则大概率每次执行都不同。
- 分组内排名必须加
ORDER BY，否则ROW_NUMBER() OVER (PARTITION BY user_id)没意义 - 累计求和（如
SUM(amount) OVER (PARTITION BY user_id ORDER BY create_time)）漏掉ORDER BY就不是“累计”，只是分组总和的重复输出 - 移动平均依赖窗口帧（
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW），但这个帧是相对于ORDER BY排序后的行定义的，不排序=帧位置漂移
移动平均怎么写才不踩 NULL 坑？
AVG() OVER() 遇到 NULL 默认跳过，看起来安全，但实际容易误判：如果原始数据里有 NULL 销售额，移动平均值会基于非空行重新计算均值，导致数值突然跳变，且行数变少。
- 先用
COALESCE(amount, 0)补零，再套窗口函数，避免统计基数变化 - 别直接对带
NULL的字段做AVG()，尤其当业务要求“把空当成 0”时 - 验证方法：查出原始数据 +
COUNT(*) OVER (...)+COUNT(amount) OVER (...)，两数不等就说明有NULL干扰了分母
分组内排名用 ROW_NUMBER 还是 RANK？
看要不要处理并列。比如按销售额排名，两个用户都是 100 万：ROW_NUMBER() 给 1 和 2，RANK() 给 1 和 1，下一个就是 3；DENSE_RANK() 则给 1 和 1，下一个直接是 2。
- 排行榜榜单（Top 10）、分页取第 N 名 → 用
ROW_NUMBER()，保证每行唯一序号 - 成绩排名、销售梯队划分 → 用
RANK()或DENSE_RANK()，保留并列语义 - 注意
RANK()会产生“空档”，比如名次是 1,1,3,4 —— 如果后续要按名次筛选“前 3 名”，RANK() 会漏掉第 4 名用户（他其实是第 3 名次）
三个窗口函数嵌套写会不会拖慢查询？
不会额外增加扫描次数，但会影响内存和排序开销。所有窗口函数共享同一套 PARTITION BY 和 ORDER BY 时，数据库通常只做一次排序；但如果各自 ORDER BY 字段不同（比如一个按时间、一个按金额），就可能触发多次排序或临时表落盘。
- 尽量复用相同的
ORDER BY字段，例如统一用ORDER BY create_time, id - 避免在一个查询里混用不同粒度的
PARTITION BY（如一个分用户，一个分月份），这会让优化器难合并执行计划 - PostgreSQL 中可用
EXPLAIN (ANALYZE, BUFFERS)看是否出现WindowAgg节点多次，SQL Server 看执行计划里的Sort是否重复
真正容易被忽略的是：窗口函数的执行时机在 GROUP BY 和 HAVING 之后、ORDER BY 之前。这意味着你不能在 WHERE 里直接过滤 ROW_NUMBER() 结果——得套一层子查询或 CTE。
