结论是分组差异化排名取决于PARTITION BY的字段组合与粒度控制：PARTITION BY user_id实现全生命周期排序，而PARTITION BY user_id, DATE(order_time)按天隔离，业务含义截然不同；多级分组下RANK()并列跳名、DENSE_RANK()并列不跳名，直接影响Top N结果稳定性；WHERE过滤须置于窗口计算之后，否则导致排名逻辑错误。
直接说结论：分组差异化排名不是靠换函数，而是靠 PARTITION BY 的字段组合与粒度控制——同一张表里，PARTITION BY user_id 和 PARTITION BY user_id, DATE(order_time) 算出来的排名根本不是一回事，业务含义也完全不同。
怎么用 PARTITION BY 控制“分组边界”
很多人以为 PARTITION BY 就是加个字段名，其实它定义的是“谁跟谁比”的逻辑边界。比如用户订单数据，想看“每个用户在每单中的下单顺序”，就得按用户+日期切；如果只写 PARTITION BY user_id，那跨天的订单也会被硬排进同一个序列，导致“第5单”实际隔了三个月。
-
PARTITION BY user_id：全生命周期排序，适合“用户总下单次数”类指标 -
PARTITION BY user_id, DATE(order_time)：按天隔离，适合“当天第几单”场景 -
PARTITION BY user_id, YEARWEEK(order_time)：按周聚合，适合复购频次分析
注意：PARTITION BY 字段顺序不影响计算结果，但影响调试时的可读性。建议把时间维度放前面（如 PARTITION BY YEAR(order_time), user_id），输出天然按年份聚类，查 2025 年 A 用户的数据不会被 2024 年 B 用户的数据打断。
多级分组下 RANK() 和 DENSE_RANK() 的行为差异
当 PARTITION BY 包含多个字段（比如 PARTITION BY region, product_category），RANK() 和 DENSE_RANK() 的区别会放大——不只是显示问题，还直接影响“Top N”能取到几行。
- 若某区域某品类下有 3 个并列销量第一，则
RANK()给三个 1，下一个排名是 4；DENSE_RANK()给三个 1，下一个是 2 - 想取“每区域每品类销量前 3 名”，用
RANK()可能只返回 1 行（因为并列太多，第 4 名才出现），而DENSE_RANK()能稳定返回最多 3 行 - 别用
ROW_NUMBER()做这种需求——它不认业务并列，纯按物理顺序硬排，容易让两个同销量商品一个排第 1、一个排第 2，引发质疑
WHERE 条件写错位置，分组就全乱了
常见错误是把过滤条件塞进窗口函数外层的 WHERE，比如想“只看销售额 > 10000 的员工在部门内的排名”，却写了：
SELECT dept, name, sales,
RANK() OVER (PARTITION BY dept ORDER BY sales DESC) AS rk
FROM employees
WHERE sales > 10000;
这会导致：每个部门只拿达标者参与排名，A 部门原本第 1 名（9500）被过滤掉，第 2 名（9200）变成新第 1 名——但业务要的是“全量排名后筛选”。正确做法必须用子查询或 CTE：
SELECT dept, name, sales, rk
FROM (
SELECT dept, name, sales,
RANK() OVER (PARTITION BY dept ORDER BY sales DESC) AS rk
FROM employees
) t
WHERE sales > 10000;
窗口函数永远在 WHERE 之后执行，这点不能绕过，也不能靠加索引优化。
ORDER BY 里有 NULL，排名可能漂移
ORDER BY 字段含空值时，不同数据库默认处理方式不一致：PostgreSQL 默认 NULLS LAST，SQL Server 可能 NULLS FIRST，MySQL 8.0+ 则需显式写 NULLS LAST 才生效。一旦字段是 updated_at 这类可能为空的时间戳，排名顺序就不可控。
- 业务上
NULL表示“未更新”，应统一转成极小值：COALESCE(updated_at, '1970-01-01') - 若必须保留
NULL语义，显式声明顺序更安全：ORDER BY updated_at DESC NULLS LAST（PostgreSQL/Oracle）或ORDER BY IFNULL(updated_at, '1970-01-01') DESC（MySQL） - 测试时务必用含
NULL的样例跑一遍，否则上线后才发现“未更新用户全排最前”，修复成本很高
