row_number() 是默认首选，因其严格保证每行唯一序号，确保 top-k 精确返回恰好 k 条记录；rank() 和 dense_rank() 在并列时会跳号或不跳号，易致漏取或超量。
直接说结论：用 ROW_NUMBER() 配合多字段 ORDER BY 是最稳妥的解法，RANK() 和 DENSE_RANK() 在存在并列时行为不同，容易漏数据或超量 —— 别图省事只按单字段排序。
为什么 ROW_NUMBER() 是默认首选？
Top-K 要的是“恰好 K 条记录”，不是“排名 ≤ K 的所有记录”。ROW_NUMBER() 严格保证每行唯一序号，哪怕多字段排序后值完全相同，也会强制分出先后（按物理顺序或主键隐式补位）。
常见错误是误用 RANK()：比如按销售额+时间双排序，若两条记录销售额相同、时间也相同，RANK() 给它们都打 1，下一条直接变 3，结果取 RANK() 可能只返回 2 行；而 <code>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
<p>注意：</p>
-
PARTITION BY dept必须写在OVER内，不能写成GROUP BY - 如果某部门只有 2 人，
rn 仍只返回这 2 条，不会补空 - MySQL 8.0+ 可用
QUALIFY rn 省一层子查询，但 Hive/Spark SQL 不支持 <code>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 是硬上限还是软门槛”——这些业务逻辑一旦定错，窗口函数再准也没用。
