rank()是窗口函数，必须在select或order by中使用，不能用于where、join等过滤条件；正确做法是先用cte或子查询计算排名，再关联使用。
为什么直接用 RANK() 会报错“窗口函数不能在 WHERE 或 JOIN 条件中使用”
因为 RANK() 是窗口函数，必须出现在 SELECT 或 ORDER BY 子句里，不能写在 ON、WHERE 或子查询的过滤条件中。常见错误是想在 JOIN 条件里直接比对排名值，比如 ON a.id = b.user_id AND b.rank = 1——此时 b.rank 还没算出来。
正确做法是：先用子查询或 CTE 把带 RANK() 的结果算好，再拿这个结果去 JOIN。
- 窗口函数必须和
PARTITION BY+ORDER BY同时出现，缺一不可 -
RANK()会为相同排序值分配相同名次，后续名次跳过（如 1,1,3），若要连续编号用ROW_NUMBER() - 如果关联表本身没有主键或存在一对多关系，
RANK()结果可能被意外重复展开，需提前去重或加限制
如何用 CTE 给订单表按用户分组排名并关联用户信息
典型场景：查每个用户的最新一笔订单，并带上用户姓名、邮箱等字段。不能只靠 MAX(order_date)，因为可能有多个同天订单；也不能只 GROUP BY user_id 然后选任意字段，会丢失关联完整性。
WITH ranked_orders AS (
SELECT
order_id,
user_id,
order_date,
amount,
RANK() OVER (PARTITION BY user_id ORDER BY order_date DESC, order_id DESC) AS rk
FROM orders
)
SELECT
u.name,
u.email,
r.order_id,
r.amount,
r.order_date
FROM ranked_orders r
JOIN users u ON r.user_id = u.id
WHERE r.rk = 1;
-
PARTITION BY user_id确保每个用户独立排名 -
ORDER BY order_date DESC, order_id DESC解决同天多单时的确定性问题 - CTE 名称
ranked_orders必须在FROM中显式引用，不能省略别名 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持该写法；SQLite 仅 3.25+ 支持窗口函数
LEFT JOIN 场景下 RANK() 结果为空怎么处理
当主表是用户表、右表是订单表，且想为每个用户附上其最高金额订单的排名（哪怕没订单），容易发现 RANK() 在 LEFT JOIN 后变成 NULL，导致 WHERE rk = 1 直接过滤掉无订单用户。
关键点：窗口函数必须在 LEFT JOIN **之前** 计算，否则 NULL 值参与 PARTITION BY 会出错或被忽略。
- 把排名逻辑放在右表的子查询里，再
LEFT JOIN这个子查询，而不是对连接后的结果算排名 - 如果右表子查询返回空行，
RANK()不会执行，但整个LEFT JOIN行仍保留，rk字段为NULL - 需要显示“无订单”的用户时，用
COALESCE(r.rk, 0)或单独判断r.order_id IS NULL
性能差？RANK() 在大表 JOIN 前没加索引会很慢
窗口函数本身不走索引，但 PARTITION BY 和 ORDER BY 字段是否建索引，极大影响排序阶段耗时。尤其当关联前的子查询扫描数百万行时，没索引会让 RANK() 变成全表排序瓶颈。
- 在
orders(user_id, order_date, order_id)上建联合索引，能同时支撑PARTITION BY user_id和ORDER BY order_date DESC, order_id DESC - 避免在
RANK()子查询里SELECT *，只取真正需要的字段，减少内存和网络开销 - PostgreSQL 中可用
EXPLAIN ANALYZE看窗口函数是否触发WindowAgg节点及排序是否用了Index Scan Backward - 如果只是取 Top 1，某些场景下用
DISTINCT ON (user_id) ORDER BY user_id, order_date DESC（PostgreSQL）反而更快
真正卡住的地方往往不是语法，而是没意识到 RANK() 是在子结果集上做全局排序——这个结果集有多大，就排多大的序。
