CASE WHEN在SELECT中用于字段值映射，必须写在SELECT子句中，按顺序匹配WHEN条件并返回对应THEN结果，务必用ELSE兜底避免NULL；不可用于WHERE左侧作动态字段选择，聚合中需配合SUM/COUNT正确处理NULL。
CASE WHEN 在 SELECT 中做字段值映射
直接用 CASE WHEN 把原始值转成业务可读的标签，比如把状态码 0、1、2 转成 '待处理'、'已通过'、'已拒绝'。注意写法顺序：必须先写 WHEN 条件，再写 THEN 结果，最后用 ELSE 拦住漏掉的值（否则会返回 NULL）。
常见错误是漏掉 ELSE，导致部分记录字段为空；或者条件写成 WHEN status = '1' 却忘了字段实际是整型，引号导致恒不成立。
CASE WHEN status = 0 THEN '待处理' WHEN status = 1 THEN '已通过' ELSE '未知状态' END AS status_label- 多个条件并列时，
CASE从上到下匹配，第一个满足的就返回，后续不再判断 - 如果只是简单等值映射，且数据库支持（如 PostgreSQL），也可考虑用
ENUM或查找表，但CASE最快、最可控
在 WHERE 中用 CASE WHEN 实现动态过滤逻辑
CASE WHEN 不能直接出现在 WHERE 的左侧（比如 CASE WHEN ... END = ? 是合法的），但不能写成 WHERE CASE WHEN a > 0 THEN b ELSE c END IN (1,2) 这种形式来“动态选择字段”——多数数据库会报错或结果不可靠。
真正安全的做法是把逻辑拆进 OR 或 AND 组合里。例如：想根据参数 @role 决定查哪些用户，@role = 'admin' 时查全部，否则只查 status = 1 的用户：
- ✅ 正确：
WHERE (@role = 'admin') OR (status = 1) - ❌ 避免：
WHERE CASE WHEN @role = 'admin' THEN 1 ELSE status END = 1（语义混乱，易出错） - 性能注意：含函数或表达式的
WHERE条件通常无法走索引，尤其当CASE包裹了字段时
聚合场景下嵌套 CASE WHEN 计算分组指标
统计报表里常要算“各渠道付费率”，就得在 SUM 或 COUNT 里嵌 CASE WHEN。关键点是：外面套聚合函数，里面写条件分支，别反了。
典型错误是写成 COUNT(CASE WHEN paid = 1 THEN user_id END) 却忘了 COUNT 会忽略 NULL，所以 ELSE NULL 可省略；但若用 SUM，就必须保证 THEN 1 ELSE 0，否则 NULL 会让整个和变 NULL。
- 付费人数：
SUM(CASE WHEN paid = 1 THEN 1 ELSE 0 END) AS paid_count - 总人数（含未付费）：
COUNT(*) AS total_count - 注意：MySQL 中
BOOL表达式可直接参与算术运算（如SUM(paid)），但 PostgreSQL 和 SQL Server 不行，必须显式转换
避免在 ORDER BY 中滥用 CASE WHEN 排序
需要按不同规则排序时（比如优先显示置顶商品，再按价格升序），CASE WHEN 确实能用，但容易写出低效 SQL。数据库优化器可能无法利用索引，尤其当 CASE 引用多个字段或带函数时。
更稳的方式是拆成 UNION ALL：先查置顶的，再查非置顶的，各自加 ORDER BY，最后合并。不过如果数据量不大，CASE 更简洁。
- 示例：
ORDER BY CASE WHEN is_top = 1 THEN 0 ELSE 1 END, price ASC - 陷阱：别在
CASE里调用函数（如UPPER(name)），会导致排序无法用索引 - PostgreSQL 支持
NULLS FIRST/LAST，有时比CASE更干净
真正麻烦的是嵌套多层 CASE 加聚合加子查询，这时逻辑已经超出 SQL 直接表达能力，该提前提取中间结果，或者交给应用层处理。
