ORDER BY中用CASE WHEN仅控制输出顺序，不生成排名；条件排名需用窗口函数（如ROW_NUMBER()）配合PARTITION BY CASE WHEN实现分组内独立编号，否则仍为全局连续编号。
为什么直接在ORDER BY里用CASE WHEN做条件排序不等于条件排名
因为 ORDER BY 只控制行输出顺序，不生成排名值；而「条件排名」意味着：对满足某条件的记录赋予高优先级序号（比如状态为'active'的排前10，其余按时间倒序补位），这必须依赖窗口函数动态计算序号。常见错误是写成 ORDER BY CASE WHEN status = 'active' THEN 0 ELSE 1 END, created_at DESC —— 这只是排序，ROW_NUMBER() 或 RANK() 仍会全局连续编号，无法实现“active组内从1开始、非active组内另起一套编号”的效果。
用嵌套窗口函数实现分组条件排名
核心思路：先用 CASE WHEN 构造逻辑分组键，再在该分组内调用窗口函数。例如按状态分两档排名：
SELECT
id,
status,
created_at,
ROW_NUMBER() OVER (
PARTITION BY CASE WHEN status = 'active' THEN 1 ELSE 0 END
ORDER BY created_at DESC
) AS rank_in_group
FROM users;
注意点：
-
PARTITION BY中的CASE WHEN必须返回确定、可比较的值（如整数或字符串），不能是表达式结果不稳定的字段 - 若需“所有 active 排前面，且整体统一编号（1~N）”，就不能用
PARTITION BY，而要改用排序权重：ORDER BY CASE WHEN status = 'active' THEN 0 ELSE 1 END, created_at DESC，再套一层ROW_NUMBER() OVER (ORDER BY ...) - MySQL 8.0+、PostgreSQL、SQL Server 支持；SQLite 不支持窗口函数，别踩坑
避免 RANK() 和 DENSE_RANK() 在条件分组里的语义混淆
当条件分组内存在相同排序键（如多个 active 用户 created_at 相同），三者行为差异立刻暴露：
-
ROW_NUMBER()：严格递增，相同时间也给不同序号 -
RANK()：跳号，比如两个并列第1，则下一个是第3 -
DENSE_RANK()：不跳号，两个并列第1，下一个是第2
业务上若要求“并列算同一档，后续不空档”，选 DENSE_RANK()；若需唯一序号（如分页取第5条），只能用 ROW_NUMBER()。别只看文档描述，实际跑一遍含重复时间的数据再决定。
性能敏感场景下如何减少窗口计算开销
条件排名本质是全表扫描+排序，数据量大时容易慢。优化方向很实际：
- 确保
ORDER BY中的字段（如created_at）有索引；PARTITION BY的分组字段（如status）最好也建索引，尤其当分组不均衡（99% 是'inactive'）时 - 避免在
CASE WHEN中调用函数（如CASE WHEN UPPER(status) = 'ACTIVE'），会导致索引失效 - 如果只要 Top N 结果，务必把
LIMIT放在最外层，而不是窗口函数里——窗口函数会先算完整结果再截断
真正卡住的往往不是语法，而是没意识到 CASE WHEN 在 PARTITION BY 里被反复求值，或误以为数据库能自动剪枝。
