直接套用 case when 在 row_number() 的 order by 中会报错，因窗口函数要求排序表达式必须确定；需先用 case 构造确定性排序列（如 sort_key），再在 over 中引用该列排序。
为什么直接套用 CASE WHEN 在 ROW_NUMBER() 里会报错？
因为窗口函数（如 ROW_NUMBER()、RANK()）的 ORDER BY 子句不接受非确定性表达式——而带 CASE WHEN 的排序键若涉及多列或 NULL 处理，容易被优化器判定为“不稳定”。常见报错是 Window function ORDER BY expression must be constant（PostgreSQL）或 SQL Server 报 Invalid column name（当 CASE 引用别名时）。
- 窗口函数的
ORDER BY必须指向原始列、确定性计算列，或已定义的列别名（取决于数据库） -
CASE WHEN可以放在窗口函数外部做条件过滤/分组，但不能直接塞进ORDER BY作为动态排序逻辑（除非你把它提前算成一个确定列）
正确写法：先用 CASE WHEN 构造排序依据列，再喂给窗口函数
核心思路是把条件逻辑“物化”为一列，再让窗口函数按这列排序。例如：对高价值客户按销售额降序排，普通客户按登录次数升序排。
SELECT
user_id,
category,
sales,
login_count,
CASE
WHEN category = 'VIP' THEN sales
ELSE -login_count -- 转为负数实现升序等效（避免用 ASC/DESC 切换）
END AS sort_key,
ROW_NUMBER() OVER (ORDER BY
CASE WHEN category = 'VIP' THEN sales END DESC,
CASE WHEN category != 'VIP' THEN login_count END ASC
) AS rank_by_category
FROM users;
- 多个
CASE WHEN并列在ORDER BY中是安全的，每支都返回确定值或 NULL，数据库会按 NULLS LAST/LAST 行为处理 - 不要用
ELSE NULL后还混排；NULL 值会导致排名“断层”或顺序不可控，建议统一补默认值（如ELSE 0或ELSE -999999） - MySQL 8.0+ 和 PostgreSQL 支持这种写法；SQL Server 需确保兼容级别 ≥ 120
用 PARTITION BY + CASE WHEN 实现分组内条件排名
真正实用的场景不是全局条件排序，而是“按用户等级分组，组内各自按不同规则排名”。这时 CASE WHEN 放在 PARTITION BY 或外层过滤更自然：
SELECT
user_id,
category,
sales,
ROW_NUMBER() OVER (
PARTITION BY category
ORDER BY
CASE category
WHEN 'VIP' THEN sales
WHEN 'PREMIUM' THEN order_count
ELSE login_count
END DESC
) AS local_rank
FROM users;
-
PARTITION BY category确保各等级独立排名，避免跨组污染 -
ORDER BY中的CASE此时是安全的：每个分区里category是常量，整个表达式退化为单列排序 - 注意：如果某类别的排序字段全为 NULL（比如
PREMIUM用户的order_count全空），该组内排名将全部为 1（因 NULL = NULL 比较失效），应提前COALESCE(order_count, 0)
性能和可读性陷阱：别在窗口函数里嵌套复杂 CASE
一旦 CASE WHEN 涉及子查询、UDF 或多表关联，性能会断崖下跌——因为窗口函数执行前，整个结果集必须完成排序，而复杂 CASE 会让优化器无法下推过滤或复用索引。
- 把
CASE逻辑尽量提到SELECT列表最前，生成中间列，再用于窗口函数 - 如果条件分支超过 4 种，考虑用查找表（
JOIN mapping_table ON ...）替代长CASE，更易维护也利于统计信息收集 - 在 PostgreSQL 中，带
CASE的ORDER BY无法走索引；若需高频查询，应建函数索引：CREATE INDEX idx_sort_key ON users ((CASE WHEN category='VIP' THEN sales END));
实际跑起来才发现，最耗时的往往不是语法写对没写对，而是 NULL 值怎么跟 CASE 交互、以及分区边界遇上空字段时窗口函数的静默行为。
