应根据并列处理需求选择：需并列不跳号用RANK()，需唯一序号用ROW_NUMBER()；RANK()更符合“前三名”业务语义，且须配合PARTITION BY分组，过滤窗口结果需子查询或CTE。
用 RANK() 还是 ROW_NUMBER()？关键看并列怎么算
如果两个供应商在同一个产品线下得分相同，你希望它们都占掉“第1名”位置（即并列不跳号），就该用 RANK()；如果必须严格按顺序给唯一序号（比如“1,2,3”哪怕分数一样），就得用 ROW_NUMBER()。多数业务场景里，RANK() 更符合“前三名”的真实语义——比如两个并列第一，那第三名其实是总分第三高的那个，不是序号为3的那个。
示例写法：
SELECT product_line, supplier_name, score,
RANK() OVER (PARTITION BY product_line ORDER BY score DESC) AS rk
FROM suppliers;
注意：PARTITION BY product_line 是分组前提，漏掉就变成全表排名了。
WHERE 不能直接过滤窗口函数结果，得套一层子查询或 CTE
RANK() 和 ROW_NUMBER() 是在 SELECT 阶段计算的，WHERE 子句执行时这些别名还不可见。直接写 WHERE rk 会报错 <code>column "rk" does not exist。
正确做法只有两种：
- 用子查询包裹：外层 WHERE 筛
rk - 用 CTE（推荐）：更清晰，也方便后续加其他逻辑
CTE 示例：
WITH ranked AS (
SELECT product_line, supplier_name, score,
RANK() OVER (PARTITION BY product_line ORDER BY score DESC) AS rk
FROM suppliers
)
SELECT product_line, supplier_name, score
FROM ranked
WHERE rk <= 3;
性能陷阱：ORDER BY 字段没索引，大数据量下会很慢
窗口函数的排序过程无法绕过 ORDER BY 字段的全量扫描。如果 score 上没索引，且 suppliers 表有百万行，每个 product_line 分组都要做局部排序，整体耗时可能翻倍。
建议操作：
- 在
(product_line, score)上建联合索引（注意顺序：先分组字段，再排序字段） - 如果
score是计算字段（比如revenue / cost），考虑物化成列再建索引 - 避免在
ORDER BY里用函数，如ORDER BY ABS(score)，会失效索引
MySQL 8.0+、PostgreSQL、SQL Server 都支持，但旧版 MySQL 不行
如果你用的是 MySQL 5.7 或更早版本，RANK() 和 ROW_NUMBER() 直接报错 FUNCTION xxx does not exist。没有替代方案能真正等价——变量模拟容易在并发或复杂 JOIN 下出错，也不保证稳定排序。
可行路径只有两个：
- 升级到 MySQL 8.0+
- 把排名逻辑移到应用层（Python/Java），先查出各 product_line 的全部数据，再用
sorted()或stream.sorted()分组处理
跨数据库移植时还要注意：ROW_NUMBER() 行为一致，但 DENSE_RANK() 在某些老 Oracle 版本里对 NULL 处理略有差异，实际跑之前最好用测试数据验证 NULL 供应商是否被纳入排名。
