不会报错，但易误用：CASE WHEN 可用于窗口函数的 ORDER BY 中构造排序键（如 ROW_NUMBER() OVER (ORDER BY CASE WHEN ... THEN 0 ELSE 1 END)），但不能直接作为未计算的逻辑表达式参与排序；必须转化为可比较值，显式处理 NULL 并统一数据类型，否则排序结果与业务预期不符。
窗口函数里直接用 CASE WHEN 会报错吗？
不会报错，但容易误以为“能用就等于能按预期排序”。CASE WHEN 可以出现在 ORDER BY 子句中（比如 ROW_NUMBER() OVER (ORDER BY CASE WHEN ...)），但不能直接作为窗口函数的排序依据字段参与计算——它得先生成一个可比较的值，而不是逻辑表达式本身。
常见错误是写成这样：
ROW_NUMBER() OVER (ORDER BY CASE WHEN status = 'active' THEN score END)结果发现
NULL 排最前，活跃用户反而靠后，因为 NULL 在默认升序中比任何数字都小。
- 必须显式处理
NULL：用ELSE补全，或用COALESCE/ISNULL - 排序方向要和业务一致：想让
'active'用户优先，就得让他们的排序键数值更小（升序）或更大（降序） - 别在
PARTITION BY里用CASE WHEN生成动态分组名——语法允许，但可读性差、维护成本高
RANK() 和 ROW_NUMBER() 在条件排名里怎么选？
取决于你是否允许并列。比如按“活跃用户优先、分数次之”排名时：
- 用
ROW_NUMBER()：即使两个活跃用户分数相同，也强制给不同序号（1, 2, 3…） - 用
RANK()：相同分数的活跃用户会共享同一排名（1, 1, 3…），空出被跳过的名次 - 用
DENSE_RANK()：同样并列，但不跳名次（1, 1, 2…）
示例（MySQL 8.0+ / PostgreSQL / SQL Server）：
SELECT id, status, score,<br> RANK() OVER (<br> ORDER BY <br> CASE WHEN status = 'active' THEN 0 ELSE 1 END,<br> score DESC<br> ) AS ranking<br>FROM users;这里用
0/1 把状态转为数值，确保活跃用户永远排前面；再按 score DESC 二次排序。
WHERE 和窗口函数里的条件逻辑冲突怎么办？
窗口函数在 WHERE 之后执行，所以 WHERE status = 'active' 会先筛数据，再排名——这和“所有用户中给活跃用户单独打高优先级”是两回事。
真正需要的是“全局排名 + 条件加权”，不是过滤。这时候得把条件逻辑放进排序键：
- 别写
WHERE status = 'active'后再排名，那是子集排名 - 要全局排名但突出某类记录，就用
CASE构造复合排序键，如(CASE WHEN ... THEN 1000000 - score ELSE score END) - 注意数据类型统一：字符串和数字混排会隐式转换出问题，显式转成同类型更稳（
CAST(... AS INT)）
PostgreSQL 和 SQL Server 的 NULL 处理差异
PostgreSQL 默认 NULLS FIRST，SQL Server 默认 NULLS LAST（虽然标准 SQL 规定 NULLS LAST 为升序默认）。当你用 CASE WHEN 返回 NULL 作排序依据时，行为可能跨库不一致。
稳妥做法是显式声明：
ORDER BY CASE WHEN status = 'active' THEN score END DESC NULLS LAST或者干脆避免
NULL：ORDER BY COALESCE(CASE WHEN status = 'active' THEN score END, -1) DESC这里用
-1 代表非活跃用户的占位分，确保他们排在最后。
实际部署前，一定要在目标数据库上验证 NULL 的排序位置——这是最容易被忽略、又最难排查的点。
