应根据是否允许并列选择：ROW_NUMBER() 严格排序取前3条，RANK() 并列同名且保留所有并列第3名；必须用 PARTITION BY 分组，配合子查询过滤 rn≤3。

用 RANK() 还是 ROW_NUMBER()？关键看重复值怎么算

每组只保留前三名，关键不在“取几条”，而在排序函数有没有选对。ROW_NUMBER() 是按顺序依次编号，规则很直接：1、2、3、4……；RANK() 则会把相同值排成并列名次，比如两个并列第1名，那下一名就会直接变成第3名。于是问题就很清楚了：如果同一组里存在并列分数、相同销售额，但又明确要求“最多只取3条记录”，那就该用 ROW_NUMBER()；反过来，如果允许并列，并且希望把所有并列第3的记录一并保留下来，比如3个人同分排在第3，那就应该用 RANK()。

常见错误是直接套 DENSE_RANK() 或没加 PARTITION BY，结果变成全局前三，不是每组前三。

• ROW_NUMBER()：适合“硬性只取3条”，不关心重复值是否挤掉名额
• RANK()：适合业务规则明确要求“并列也算进前三”的场景（如竞赛榜单）
• 必须写 PARTITION BY group_column，否则窗口不分组，全是整体排序
• 排序字段建议非空，NULL 值在多数数据库中默认排最前或最后，容易意外吞掉本该上榜的记录

写法模板：子查询 + WHERE 过滤是最稳的

窗口函数不能直接在 WHERE 中使用，所以得套一层子查询或 CTE。别试图在原表上加 HA VING 或改 GROUP BY，那根本不管用。

SELECT * FROM (
SELECT *,
 ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC) AS rn
FROM orders
) t
WHERE t.rn <= 3;

• 别漏写别名 t，MySQL 8.0+ 和 PostgreSQL 要求子查询必须有别名
• PostgreSQL 支持直接用 WITH CTE，可读性更好，但执行逻辑一样
• SQL Server 2005+、Oracle、MySQL 8.0+ 都支持，但 MySQL 5.7 不支持窗口函数，会报错 ERROR 1064
• 如果原表很大，记得在 (category, sales) 上建联合索引，否则 ORDER BY 在每组内排序可能变慢

遇到 NULL 怎么办？提前 COALESCE 或 IS NULL 处理

当排序字段（比如 score）含 NULL，默认行为因数据库而异：PostgreSQL 把 NULL 排最后，MySQL 8.0 默认排最前。这会导致 NULL 记录意外占掉第1~3名位置，把真实数据挤出去。

• 统一处理方式：用 COALESCE(score, -999999) 把 NULL 当极小值，确保它排末尾
• 或者显式控制：写 ORDER BY score DESC NULLS LAST（PostgreSQL 支持，MySQL 不支持该语法）
• 更安全的做法是在子查询外再加过滤：WHERE score IS NOT NULL，先剔除无效数据再排名

性能卡在哪？注意分区键选择和数据倾斜

窗口函数性能瓶颈不在函数本身，而在 PARTITION BY 字段的分布。如果某组（比如 category = 'unknown'）占了全表 80% 数据，那一组内部排序就会拖慢整体查询。

• 检查分区字段的值分布：SELECT category, COUNT(*) FROM orders GROUP BY category ORDER BY 2 DESC LIMIT 5;
• 避免用高基数字段（如 user_id）做分区——除非真要每个用户取前三，否则容易生成大量小窗口，调度开销反而上升
• 如果只是临时查报表，加 LIMIT 没用，窗口函数仍需扫描全部数据；真要提速，得靠索引或预计算聚合表

真正容易被忽略的是：窗口函数的 ORDER BY 是每组独立排序，不是全局排序后切片。很多人误以为“先排好序再分组取前3”，实际是“先分组，再在每组里排序”。这个逻辑一旦理解反了，写出的 SQL 就永远不对。

《夸克》非常好用的免费AI浏览器

下载APP查看