ROW_NUMBER() 需配合 CASE 写在窗口函数 ORDER BY 中实现自定义排序排名，如按 shipped→pending→cancelled 优先级编号；CASE 各分支类型须一致且建议用整数，需含 ELSE 避免 NULL 排序异常；RANK() 与 DENSE_RANK() 仅影响并列处理方式，不改变排序逻辑。
用 ROW_NUMBER() 配合 CASE 实现自定义顺序的组内排名
直接结论：窗口函数本身不支持“按业务规则排序后再编号”，必须把自定义排序逻辑塞进 ORDER BY 子句里，而 CASE 是最常用、最可控的手段。
比如订单表里要按「已发货 > 待发货 > 已取消」这个优先级给每个用户下的订单排号，就不能靠字段原值排序，得先映射成数字再排：
SELECT
user_id,
status,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY CASE status
WHEN 'shipped' THEN 1
WHEN 'pending' THEN 2
WHEN 'cancelled' THEN 3
ELSE 4
END
) AS rank_in_user
FROM orders;
-
CASE必须写在窗口函数的ORDER BY里，不能在外面套一层再排序 - 每个分支返回的类型要一致（推荐全用整数），否则某些数据库（如 PostgreSQL）会报类型冲突
- 漏掉
ELSE可能导致 NULL 值排在最前（取决于数据库默认 NULLS FIRST/FIRST），建议显式定义兜底值
为什么不用 RANK() 或 DENSE_RANK()？
这三个函数只在「并列如何处理」上不同，底层都依赖同一个 ORDER BY 结果。你用 CASE 定义好了顺序，选哪个函数只影响重复值的编号方式，和“自定义排序”本身无关。
比如两个订单状态都是 'pending'，用 ROW_NUMBER() 会强制分出 1 和 2；RANK() 给它们都标 1，下一个标 3；DENSE_RANK() 也标 1，下一个标 2。选谁取决于业务是否允许并列名次。
- 要严格递增不跳号 → 用
ROW_NUMBER() - 要体现“并列第一，下一个是第三” → 用
RANK() - 要体现“并列第一，下一个是第二” → 用
DENSE_RANK() - 别在
CASE里返回字符串（如'1'）去试图控制顺序——字符串字典序和数字大小序不是一回事
MySQL 8.0+ 和 PostgreSQL 的兼容性细节
主流新版本都支持在窗口函数 ORDER BY 里直接写 CASE，但旧版 MySQL（
- PostgreSQL 要求
CASE表达式必须是“可排序的”（sortable），返回数值或文本都行，但不能是数组、JSON 等复合类型 - SQLite 从 3.25.0 开始支持窗口函数，但对
CASE在ORDER BY中的支持较弱，建议升级到 3.30+ - 如果遇到
ERROR: window function not allowed here，大概率是把窗口函数写在了 WHERE 或 GROUP BY 里，它只能出现在 SELECT 或 ORDER BY 中
性能隐患：CASE 太复杂会拖慢排序
窗口函数的排序是真实发生的物理操作，CASE 表达式越重，每行计算开销越大，尤其当分区数据量大时（比如单个 user_id 有上万条记录）。
- 避免在
CASE里调用子查询、UDF 或字符串函数（如REGEXP） - 如果自定义顺序规则稳定（如状态码映射），优先建一个带排序权重的维表，用
JOIN替代内联CASE - 确认执行计划里是否走了索引——加在
(user_id, status)上的联合索引对这类查询帮助有限，因为CASE打乱了原始status顺序
CASE 分支覆盖不全 + 数据库对 NULL 的默认排序行为，这两点一碰上，排名就悄无声息地错位。 
