应根据是否需要保留名次空缺选择：ROW_NUMBER() 强制唯一编号，DENSE_RANK() 并列不跳号，RANK() 并列后跳号；去重需配合QUALIFY或子查询，不可仅依赖排序函数。
用 ROW_NUMBER() 还是 DENSE_RANK()？看你要不要保留名次空缺
分组内去重排序的核心，其实是「先去重，再排序」还是「在排序中跳过重复」——这两者语义不同。ROW_NUMBER() 给每行唯一编号，哪怕值相同也强行排开；DENSE_RANK() 遇到相同值会并列，且后续名次不跳号；RANK() 并列后会跳号。比如分组内有三个 'A'，DENSE_RANK() 返回 1,1,1,2...，ROW_NUMBER() 返回 1,2,3,4...。
真正去重（即每个唯一值只留一条）必须配合 QUALIFY 或子查询过滤，不能只靠排序函数本身。
- 要保留每个分组里「首次出现的重复值」：用
ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY sort_col)+WHERE rn = 1 - 要按业务值「逻辑去重后排序」（如取每个
user_id的最新订单）：先ORDER BY created_at DESC，再ROW_NUMBER() = 1 -
DENSE_RANK()适合做「去重后的连续名次」展示，但不能直接删掉重复行
为什么 SELECT DISTINCT + GROUP BY 不能替代窗口函数？
因为 DISTINCT 是全字段去重，而分组内去重排序往往需要保留其他字段（比如取每个部门薪资最高的员工姓名、入职时间），GROUP BY 又强制要求所有非聚合字段都出现在 GROUP BY 列表里，极易报错或逻辑错误。
典型翻车场景：SELECT dept, name, MAX(salary) FROM emp GROUP BY dept —— name 不在 GROUP BY 中，MySQL 5.7+ 和大多数数据库会直接报错；即使开启 sql_mode=ONLY_FULL_GROUP_BY 关闭，返回的 name 也是随机的，不是最高薪那个人的。
- 窗口函数天然支持「分组内计算」而不破坏原始行结构
- 可同时输出原始字段 + 排序序号 + 是否为 Top1 标志，灵活组合
- 避免自连接或相关子查询带来的性能陡增（尤其数据量 > 10 万行时）
QUALIFY 是最简写法，但注意数据库支持度
QUALIFY 是 BigQuery、Snowflake、Trino 等现代数仓的语法糖，能直接在窗口函数结果上过滤，省去一层子查询。例如：
SELECT user_id, item_id, created_at FROM events QUALIFY ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) = 1
但 PostgreSQL、SQL Server、MySQL（截至 8.0）不支持 QUALIFY，必须套子查询：
SELECT user_id, item_id, created_at
FROM (
SELECT user_id, item_id, created_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
FROM events
) t
WHERE rn = 1
- PostgreSQL 用户可用
DISTINCT ON (user_id) ORDER BY user_id, created_at DESC替代，但仅限单字段分组且排序字段需对齐 - MySQL 8.0+ 支持窗口函数，但没
QUALIFY，务必写子查询 - Oracle 用户注意
ROW_NUMBER()的ORDER BY必须明确，空值默认排最后，可能影响「首个」判断
排序字段含空值或时区时间时，ORDER BY 的写法很关键
窗口函数的 ORDER BY 子句决定「谁排第一」，一旦字段含 NULL 或跨时区时间戳，结果可能和预期不符。比如 created_at 为空的记录，在 ORDER BY created_at DESC 下会被排在最前（多数数据库把 NULL 当最大值），导致 ROW_NUMBER() = 1 拿到的是脏数据。
- 显式控制
NULL位置：ORDER BY created_at DESC NULLS LAST（PostgreSQL/Oracle 支持），MySQL 和 SQL Server 需用COALESCE(created_at, '1970-01-01')等兜底 - 比较时间字段前先统一时区：
CONVERT_TZ(created_at, '+00:00', @@session.time_zone)或用created_at AT TIME ZONE 'UTC'（依数据库而定） - 多条件排序更安全：比如
ORDER BY status DESC, updated_at DESC，避免仅靠时间戳无法区分先后
真正难的不是写出窗口函数，而是想清楚「去重依据是什么」——是时间？是版本号？是业务状态优先级？这个逻辑一旦错，后面所有排序都白搭。
