CASE WHEN 不能用于子查询的 WHERE 或 JOIN 条件，但可安全用于 SELECT 列、聚合函数内或作为子查询输出字段；必须返回统一类型的标量值，且需显式写 ELSE 避免 NULL 导致过滤遗漏。
CASE WHEN 不能直接在子查询的 WHERE 或 JOIN 条件里当控制语句用，但可以安全、高效地嵌在 SELECT 列、聚合函数内部、或作为子查询的输出字段参与外层逻辑——关键在于“它必须产出标量值”，而不是替代布尔表达式。
子查询中用 CASE WHEN 做打标字段（最常用且安全）
这是生产环境最推荐的做法：把复杂判断封装成一个带标签的列，在子查询里算好，外层再按这个标签筛选或分组。
- 适合场景：用户分级（VIP/高危/拉黑）、订单状态映射（'paid' → '已支付'）、金额区间打标（
amount→ 'small/medium/large'） - 必须显式写
ELSE，否则不匹配行会变成NULL，外层WHERE label = 'VIP'会漏掉这些行 - 所有
THEN分支返回值类型要一致，比如混用'high'和100，MySQL 可能转成字符串，PostgreSQL 直接报错 - 示例（打标后外层过滤）：
SELECT * FROM ( SELECT user_id, CASE WHEN EXISTS (SELECT 1 FROM blacklist b WHERE b.user_id = u.id) THEN 'blocked' WHEN total_amount >= 10000 THEN 'high' WHEN total_amount >= 1000 THEN 'med' ELSE 'low' END AS risk_level FROM users u) t WHERE t.risk_level = 'high';
聚合函数内嵌 CASE WHEN 实现条件统计（不可替代）
这是子查询里唯一真正需要嵌套 CASE WHEN 的地方：在 SUM、COUNT、AVG 等函数内部做条件计算，避免多次扫描表。
- 常见错误：把
CASE WHEN写在聚合函数外面，比如CASE WHEN status = 'paid' THEN SUM(amount) END—— 这会导致语法错误或全为NULL -
COUNT要小心：匹配不到时必须返回NULL（别写ELSE 0），否则COUNT(0)也会被计数 - 性能影响：数据库能将其优化为单次扫描 + 条件累加，比用多个子查询或
UNION ALL快得多 - 示例（子查询中一次算出多维指标）：
SELECT region, COUNT(*) AS total_orders, SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS paid_cnt, SUM(CASE WHEN status = 'refunded' THEN amount ELSE 0 END) AS refund_amt FROM orders GROUP BY region;
嵌套子查询中用 CASE WHEN 处理 NULL 和多级判断
当判断逻辑本身依赖另一个子查询结果（比如先查是否在黑名单，再查消费额），需要用搜索型 CASE WHEN 显式处理 NULL，并注意嵌套层级的 END 配对。
- 别用简单型语法
CASE col WHEN ...，它对NULL不生效；必须用搜索型CASE WHEN col IS NULL THEN ... - 每层
CASE必须有对应END，嵌套两层就至少两个END，漏一个就会报missing keyword END - EXISTS 子查询天然返回布尔值，和
CASE WHEN配合极自然，但注意外层CASE优先级更高，确保blocked不会被后续分支覆盖 - 示例（含 NULL 安全和嵌套）：
SELECT id, CASE WHEN EXISTS (SELECT 1 FROM blacklist b WHERE b.user_id = u.id) THEN 'blocked' WHEN (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) > 0 THEN CASE WHEN u.total_amount >= 5000 THEN 'active_high' ELSE 'active_low' END ELSE 'inactive' END AS statusFROM users u;
最容易被忽略的是类型兼容性与 NULL 处理：同一个 CASE 所有分支返回值类型不一致，可能让整列变成 TEXT，导致后续数值比较失效；而漏掉 ELSE 或没处理 IS NULL，会让业务逻辑在边界 case 上静默失败——这两点在线上查问题时最难定位。
