rank()跳号、dense_rank()不跳号是设计意图：前者按“段位断层”计算（并列共享名次，下一段名次=当前名次+并列行数），后者按“档位连续”计算（值变则名次+1）。
为什么直接 GROUP BY + ORDER BY 会漏掉并列排名？
社交媒体里常要显示“今日点赞 Top 10”，但用户 A 和 B 都获 99 个赞时，按 ORDER BY like_count DESC LIMIT 10 会随机截断，可能把 B 挤出去——这不是业务想要的“并列第 3 名”。窗口函数能保留所有并列项，靠的是在不打乱原始行的前提下计算排名。
RANK() 和 DENSE_RANK() 在点赞榜里怎么选？
两者都处理并列，但跳名规则不同：RANK() 并列后跳位（99 赞两人并列第 1，则下一位是第 3），DENSE_RANK() 不跳（下一位是第 2）。实际用哪一种，取决于产品是否允许“空档名次”：
- 榜单展示页通常用
DENSE_RANK()：用户看到“第 1、第 1、第 2”更符合直觉 - 运营后台做分段统计（如“前 3 名用户”）可能用
RANK()：避免把第 4 名误纳入“前三”
示例语句：
SELECT user_id, like_count,<br> DENSE_RANK() OVER (ORDER BY like_count DESC) AS rank_num<br>FROM post_likes_daily<br>WHERE date = '2024-06-15';
窗口函数加 FILTER 子句能避开临时表吗？
想统计“每个用户本周总点赞数 + 在全站的实时排名”，传统做法是先 GROUP BY user_id 写入临时表，再查排名。用窗口函数可一步到位，但要注意 PostgreSQL 支持 FILTER，MySQL 不支持：
- PostgreSQL 可写：
SUM(like_count) FILTER (WHERE date >= CURRENT_DATE - INTERVAL '7 days') OVER (PARTITION BY user_id) - MySQL 必须用
CASE WHEN替代：SUM(CASE WHEN date >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) THEN like_count ELSE 0 END) OVER (PARTITION BY user_id) - 别在
OVER里写WHERE——语法错误，窗口函数不接受 WHERE 过滤行
排序字段为空或重复时排名会崩吗？
点赞数为 NULL 的记录默认排在最后（PostgreSQL）或最前（MySQL），导致排名错乱。更危险的是大量用户点赞数相同（比如都是 0），RANK() 会把所有人标成第 1 名——这会让 LIMIT 10 返回上千行。
- 务必在
ORDER BY后加二级排序，例如：ORDER BY like_count DESC, user_id ASC - 对
NULL显式处理：ORDER BY COALESCE(like_count, 0) DESC - 如果业务允许，把排名结果缓存到带 TTL 的 Redis 中，避免每次请求都重算全量窗口
真正麻烦的不是语法，而是当点赞数分布极度倾斜（比如 95% 用户为 0）时，DENSE_RANK() 仍会为每个 0 值用户分配相同排名，而应用层未必能高效渲染上千个“第 1 名”。这时候得回到业务逻辑：是否真需要给零点赞用户排名？
