CASE WHEN 配合窗口函数的使用技巧，很多开发者以为只是简单的嵌套组合，实际上背后隐藏着三种截然不同的“逻辑触发时机”。它们解决的不是“怎么写代码”的问题，而是“在计算链条的哪个节点插入判断条件”——这个时间顺序决定了最终数据的准确性和查询性能。下面详细拆解这三种嵌套方式，帮助你掌握SQL窗口函数的高级优化方法。
外部嵌套CASE WHEN：先执行窗口函数再筛选结果
这是最直观的写法，也是初学者最容易出错的地方。例如想要给高分学生计算排名，其他学生直接标记为“未参与”，很多人的第一反应是这么写：
CASE WHEN score >= 90 THEN RANK() OVER (ORDER BY score DESC) ELSE '未参与' END
注意，这里有一个性能陷阱：RANK() 实际上会对所有行都执行排序操作，即使那些分数低于 90 的行也参与了排序。最后通过外层的 CASE WHEN 只展示部分结果。如果表中有 100 万行数据，数据库引擎仍然需要全量排序，性能开销相当大。
那么什么时候适合这种写法？只有当你需要保留完整的窗口计算上下文（例如后续要配合 ROWS BETWEEN 进行更细粒度的分析），或者仅仅是对展示层结果做映射时，才推荐使用。否则，考虑更高效的替代方案。
几个容易踩坑的注意事项：
ELSE分支返回的数据类型必须与窗口函数的返回值兼容，否则会报类似ORA-00932的类型错误。- 不能写成
CASE WHEN RANK() > 10 THEN ...—— 窗口函数不能直接放在WHEN的条件中，这是语法限制。
参数内嵌CASE WHEN：过滤输入数据，影响计算基数
这才是“按需计算”的核心技巧。例如只希望对已支付的订单进行累计金额统计，通常的做法是写子查询先过滤，但更优雅的方式是直接将判断逻辑嵌入聚合函数的参数中：
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) OVER (ORDER BY create_time)
这里的精髓在于 CASE WHEN ... ELSE 0。将未支付订单的金额设为 0 而非 NULL，可以保证窗口函数的累加逻辑连续。如果使用 NULL，SUM 函数会跳过该行，导致当前行的累计值变成 NULL，从而中断累加曲线。
使用这种写法时需要注意：
ELSE必须显式写出，不能省略。省略时默认是ELSE NULL，这会破坏聚合的连续性。- 不同聚合函数对
NULL的敏感度不同。例如AVG()和COUNT()，如果使用NULL作为ELSE，计算结果容易偏离预期。因此建议谨慎使用NULL。 - 这种方法不适用于
RANK()、ROW_NUMBER()等序号函数，因为它们不接受CASE WHEN作为参数，强行使用会报错。
OVER子句内动态分区：将业务规则直接映射为SQL结构
这是最灵活的用法。当分区逻辑需要动态计算时，例如“根据用户当前积分实时判定等级，再按等级分组排名”，可以直接将判断逻辑写在 PARTITION BY 中：
RANK() OVER ( PARTITION BY CASE WHEN points >= 10000 THEN 'VIP' WHEN points >= 1000 THEN 'Gold' ELSE 'Normal' END ORDER BY order_count DESC)
这里 PARTITION BY 不再是固定的字段，而是一段可执行的逻辑。数据库会在运行时为每一行计算分区标签，然后根据这个动态标签完成分组计算。
使用这种高级写法时需特别注意：
- 所有
WHEN分支返回的数据类型必须一致，例如都是字符串，否则会直接报类型不匹配错误。 CASE WHEN内部不能引用任何窗口函数（如ROW_NUMBER()），也不能引用本层OVER中的排序字段。- 务必留意
NULL值的处理。如果某行points为NULL，整个CASE返回NULL，这些行不会被丢弃，而是归入一个隐式分区。你可能在排名结果中看到莫名其妙的“空分区”排名组。
一个容易被忽略的细节：ELSE不是兜底，而是逻辑断点
最后，我想特别强调一点。许多生产环节的问题，根源都在于把 ELSE 当作“安全兜底”来使用。实际上，一旦业务状态新增（例如订单表突然增加了 refunding 状态，但你的 CASE WHEN 没有覆盖），所有未匹配的数据会全部流入 ELSE 分支。如果你写了 ELSE '其他'，这个“其他”里可能混入灰度测试数据、脏数据，甚至系统异常码。更危险的是，有些团队为图省事直接写 ELSE NULL，导致下游报表整行数据被丢弃，统计口径在不知不觉中漂移。
真正稳健的做法是：明确枚举所有已知状态，并用注释标注版本和生效时间。在 ELSE 中写一个能一眼识别的占位符，例如 'UNEXPECTED_STATUS_' || status，让问题暴露在日志或监控中。不要让它沉默地吞噬数据，等出了问题才追悔莫及。
