窗口函数替代GROUP BY时必须显式声明ORDER BY，否则结果无序且不稳定；空OVER()会触发全表排序，嵌套窗口函数易致多次扫描，性能下降显著。
窗口函数替代 GROUP BY + 子查询时，ORDER BY 必须显式声明
很多同学把 ROW_NUMBER() 或 RANK() 套进子查询里，以为能直接“降维”替代分组聚合，结果发现结果乱序、重复或报错。根本原因是：窗口函数不保证输出顺序，除非你写明 ORDER BY 子句。
常见错误现象：SELECT id, ROW_NUMBER() OVER (PARTITION BY category) FROM t —— 缺少 ORDER BY，数据库可能按任意物理顺序编号，每次执行结果都可能不同。
- 必须写成
ROW_NUMBER() OVER (PARTITION BY category ORDER BY created_at DESC) - 如果业务逻辑依赖“最新一条”，
ORDER BY不能只靠主键或时间字段的默认索引，要显式指定且确保该列非空、有索引 - MySQL 8.0+ 和 PostgreSQL 支持，但旧版 MySQL（5.7）根本不支持窗口函数，别在生产环境硬套
OVER () 空括号写法会触发全表排序，性能杀手
写 COUNT(*) OVER () 看似只是加个总数列，但实际会让优化器对整张表做一次隐式排序（尤其在 PostgreSQL 中），即使你没写 ORDER BY。这是因为某些引擎把空 OVER 视为“全局窗口”，而实现上依赖排序缓冲区。
使用场景：需要每行都带总行数、最大值等聚合指标，但又不想多扫一遍表。
- PostgreSQL 中，改用
count(*) OVER ()配合SELECT DISTINCT ON或提前物化中间结果更稳 - SQL Server 可以用
OPTION (RECOMPILE)让优化器感知参数变化，避免缓存低效执行计划 - 如果只是要总行数，优先考虑先查
SELECT COUNT(*) FROM t，再 JOIN 回去——比窗口函数更可控
嵌套窗口函数（如 ROW_NUMBER() OVER (ORDER BY ...) 套在 MAX() OVER (PARTITION BY ...) 里）容易触发多次扫描
一个语句里出现多个不同 PARTITION BY 或不同 ORDER BY 的窗口函数，PostgreSQL 和 SQL Server 往往无法复用排序结果，会分别排序两次甚至三次。实测大表（千万级）下，耗时可能翻倍。
性能影响：IO 增加、内存占用飙升、临时磁盘排序频繁。
- 优先合并逻辑：比如用
MAX(created_at) OVER (PARTITION BY user_id)替代先算ROW_NUMBER()再过滤 top1 - 如果必须多维度排序，考虑用 CTE 提前按最重的
PARTITION BY+ORDER BY排好，后续窗口函数复用结果集 - 注意 Hive/Spark SQL 对嵌套窗口支持有限，
OVER里不能嵌套另一个窗口函数，会直接报Unsupported SubQuery Expression
WHERE 条件写在窗口函数外层，但误放内层子查询导致逻辑错误
典型翻车现场：想查“每个部门薪资前三的人”，却写成 SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) rn FROM t WHERE status = 'active') t2 WHERE rn —— 看似合理，但如果 <code>WHERE 在子查询里，就先筛掉了人，再排名；而真实需求往往是“所有在职人员中取前三”，但数据里可能混着已离职者，得先排名再过滤。
关键区别在于过滤时机：窗口函数运行在 WHERE 之后、GROUP BY 之前（标准 SQL 执行顺序），所以 WHERE 放哪，决定了参与排名的数据集大小。
- 正确做法是把业务过滤条件尽量留在外层，或用
FILTER（PostgreSQL）/CASE WHEN（通用）控制窗口内聚合范围 - 例如统计“在职员工的平均薪资”，别用
AVG(salary) OVER (PARTITION BY dept)，而用AVG(CASE WHEN status = 'active' THEN salary END) OVER (PARTITION BY dept) - MySQL 8.0 不支持
FILTER，只能靠CASE WHEN模拟，注意 NULL 处理——AVG()会自动忽略 NULL，但SUM()/COUNT()不会，别算错分母
窗口函数不是银弹，它省掉的是 JOIN 和子查询结构，换来的可能是隐式排序和内存压力。真正卡顿的时候，先看执行计划里的 Sort 节点有没有意外膨胀，再回头检查 OVER 里写了几个不同的 PARTITION BY 和 ORDER BY 组合。
