row_number() 是分组 top n 最常用的选择，因其严格按排序生成唯一序号、不跳号不并列，能精准截取前 n 行；而 rank() 和 dense_rank() 因处理并列导致行数不可控。
为什么 ROW_NUMBER() 是分组 Top N 最常用的选择
因为它的行为最可控：严格按排序生成唯一序号，不会跳号、不会并列，适合“取前 N 条”这种硬性截断需求。比如要查每个部门薪资最高的 3 个人，ROW_NUMBER() 能确保正好返回 3 行（即使第 3 名有多人并列，也只随机选一个）。
常见错误是误用 RANK() 或 DENSE_RANK()——它们会为相同值分配相同排名，导致实际返回行数远超 N。例如两人并列第 1，RANK() 给他们都是 1，下一个是 3，WHERE rn 就可能取到 4 行。
实操建议：
- 写法固定：
ROW_NUMBER() OVER (PARTITION BY department ORDER BY salary DESC) -
PARTITION BY后必须是分组字段，不能是表达式或别名 - 排序字段最好有唯一键兜底，比如
ORDER BY salary DESC, emp_id ASC，避免因排序不稳定导致结果波动
在 WHERE 中直接过滤窗口函数结果会报错
SQL 标准规定窗口函数不能出现在 WHERE 子句里，因为执行顺序是 WHERE → GROUP BY → HAVING → SELECT → WINDOW → ORDER BY，窗口计算发生在 WHERE 之后。直接写 WHERE ROW_NUMBER() OVER (...) 会报错 <code>Window function is not allowed in WHERE clause。
正确做法只有两种：
- 用子查询或 CTE 包一层，把窗口函数放在内层
SELECT中，外层再WHERE rn - 用
QUALIFY（仅支持 BigQuery、Snowflake、Doris 等少数引擎），它专为过滤窗口结果设计，语法简洁：QUALIFY ROW_NUMBER() OVER (...)
注意：MySQL 8.0+ 和 PostgreSQL 都不支持 QUALIFY，必须套子查询。
MySQL 8.0+ 和 PostgreSQL 的写法差异很小但关键
两者都支持标准窗口函数，语法几乎一致，但 MySQL 对子查询别名要求更严格，PostgreSQL 允许省略别名。
MySQL 必须写：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn FROM employees ) t WHERE t.rn <= 3;
PostgreSQL 可以省略 t 别名（但建议保留，提高可读性）：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn FROM employees ) WHERE rn <= 3;
性能提示：如果原表很大，务必在 PARTITION BY 和 ORDER BY 字段上有联合索引，比如 (dept, salary)，否则窗口计算会全表扫描。
Top N 带条件时，先过滤再开窗更高效
比如“查每个部门薪资前 3 的**在职员工**”，如果在窗口函数外层用 WHERE status = 'active'，是正确的；但如果写成 ROW_NUMBER() OVER (PARTITION BY dept ORDER BY CASE WHEN status='active' THEN salary END DESC)，就错了——CASE 会让非在职员工排在最前（NULL 默认最大），且排序不稳定。
正确姿势永远是：先用 WHERE 过滤数据，再对结果集开窗。
- 错误：在
ORDER BY里混条件逻辑 - 正确：在子查询或 CTE 的最外层
WHERE过滤业务状态 - 额外注意：
PARTITION BY字段本身也要确保已过滤，比如部门字段为 NULL 的记录会自成一组，可能意外产出“Top N”结果
真正容易被忽略的是空值处理——PARTITION BY 或 ORDER BY 字段含 NULL 时，不同数据库行为不一，PostgreSQL 把 NULL 当最大值，MySQL 默认当最小值，上线前务必验证 NULL 数据的归属。
