在 SQL 世界里，窗口函数是处理 Top-K 类问题的利器，但用对了是利器，用错了就可能变成“漏数据”的隐患。先直接说结论：用 ROW_NUMBER() 配合多字段 ORDER BY 是最稳妥的解法。而 RANK() 和 DENSE_RANK() 呢？它们在存在并列时行为不同，容易漏数据或超量——所以，别图省事只按单字段排序。
为什么 ROW_NUMBER() 是默认首选？
Top-K 要的是“恰好 K 条记录”，不是“排名 ≤ K 的所有记录”。ROW_NUMBER() 严格保证每行唯一序号，哪怕多字段排序后值完全相同，也会强制分出先后（按物理顺序或主键隐式补位）。
一个常见错误是误用 RANK()。举个例子：按销售额+时间做双排序，如果两条记录销售额相同、时间也相同，RANK() 会给它们都打上 1，下一条直接跳到 3。这时取 RANK() <= K，结果可能只返回 2 行；而 ROW_NUMBER() 会标为 1/2/3，稳稳拿满 3 条。
实操建议：
- 始终把业务上“必须打破并列”的字段（如
id、created_at）放在ORDER BY最末位。 - 避免在
ORDER BY中使用无索引字段，否则窗口函数性能会断崖下跌。 - PostgreSQL 和 MySQL 8.0+ 支持标准语法；SQLite 3.25+ 仅支持
ROW_NUMBER()，不支持QUALIFY。
如何写一个带分组的多条件 Top-K？
举一个典型场景：每个部门薪资最高的 3 人，同薪时按工龄降序，工龄相同时按姓名升序。这就是典型的 PARTITION BY + 多级 ORDER BY。
关键点在于：窗口函数的 ORDER BY 只影响序号生成，不影响最终结果行数；真正控制“每组几条”是外层过滤。
示例（兼容多数数据库）：
SELECT dept, name, salary, years_of_service
FROM (
SELECT dept, name, salary, years_of_service,
ROW_NUMBER() OVER (
PARTITION BY dept
ORDER BY salary DESC, years_of_service DESC, name ASC
) AS rn
FROM employees
) t
WHERE rn <= 3;
注意：
PARTITION BY dept必须写在OVER内，不能写成GROUP BY。- 如果某部门只有 2 人，
rn <= 3仍只返回这 2 条，不会补空。 - MySQL 8.0+ 可用
QUALIFY rn <= 3省一层子查询，但 Hive/Spark SQL 不支持QUALIFY。
遇到 NULL 怎么办？排序时被甩到最前还是最后？
默认行为因数据库而异：NULLS FIRST 或 NULLS LAST 才是可控解法。不显式声明，PostgreSQL 默认 NULLS FIRST（升序时排最前），MySQL 8.0+ 默认 NULLS LAST（升序时排最后），SQL Server 直接报错。
在多条件排序中，一个字段为 NULL 就可能让整行掉出 Top-K，必须明确控制：
- 想把 NULL 当最小值处理（即升序时放最后）：加
NULLS LAST。 - 想把 NULL 当最大值处理（即降序时放最前）：加
NULLS FIRST。 - 示例：按业绩排序，未填报者（NULL）视为 0，应排在最低档 →
ORDER BY performance DESC NULLS LAST。
说到底，真正难的不是写出语法，而是想清楚三件事：并列是否允许？NULL 代表什么语义？K 是硬上限还是软门槛？这些业务逻辑一旦定错，窗口函数再准也没用。
