CASE WHEN 必须以END结尾，THEN后各分支类型需一致，ELSE不可省略；WHERE中应避免使用CASE，优先用布尔逻辑；GROUP BY/ORDER BY引用时需与SELECT中表达式完全一致；处理NULL和空字符串需显式判断。
SELECT 中的 CASE WHEN 语法结构怎么写才不报错
直接写 CASE WHEN 最容易漏掉 END 或混淆 THEN 后面的表达式类型。它不是函数调用，而是一条完整语句块，必须成对出现。
-
CASE后不能跟括号（CASE (col)是错的），正确写法是CASE WHEN col > 10 THEN 'big' ELSE 'small' END - 所有
THEN分支返回值类型要尽量一致：比如都返回字符串，或都返回数字；混用会导致隐式转换失败（尤其在 PostgreSQL 或 SQL Server 中） -
ELSE不是可选的——不写时默认为NULL，但如果你后续做WHERE过滤或聚合，NULL可能引发意外结果 - 嵌套
CASE时，每个CASE都要有自己的END，别指望一个END收尾两层逻辑
WHERE 条件里能不能用 CASE WHEN
能，但没必要，而且容易写错。绝大多数场景应该用布尔逻辑替代。
- 错误写法：
WHERE CASE WHEN status = 'active' THEN 1 ELSE 0 END = 1—— 多余绕弯，还可能让索引失效 - 正确写法：
WHERE status = 'active'，或者多条件组合：WHERE (type = 'A' AND amount > 100) OR (type = 'B' AND amount > 50) - 真需要动态条件（比如参数控制过滤逻辑），应优先考虑应用层拼接 SQL 或用
COALESCE/NULLIF配合参数占位，而不是硬塞CASE到WHERE - 唯一合理用例：当字段本身是表达式、且需按不同规则判别真假时，例如
WHERE CASE WHEN is_archived = 1 THEN created_at NOW() - INTERVAL '7 days' END—— 但这种也建议拆成两个查询分支更清晰
GROUP BY 或 ORDER BY 里引用 CASE 表达式要注意什么
可以引用，但必须和 SELECT 中的别名或完整表达式完全一致，数据库不会自动“理解”你指哪个字段。
- 如果 SELECT 写了
CASE WHEN score >= 90 THEN 'A' ... END AS grade，那么GROUP BY grade在 MySQL 8.0+ 和 PostgreSQL 中合法，但在 SQLite 或旧版 MySQL 中会报错，得写成GROUP BY CASE WHEN score >= 90 THEN 'A' ... END -
ORDER BY同理：别依赖别名，尤其跨数据库迁移时；更稳妥的是用列序号（如ORDER BY 2），但可读性差，仅限简单查询临时用 - 性能上，
GROUP BY含复杂CASE会显著拖慢执行，因为无法利用原始字段索引；如有高频分组需求，建议提前物化该分类字段（加计算列或维护冗余字段）
用 CASE WHEN 做行级数据转换时，NULL 和空字符串怎么处理
这是最常踩的坑：你以为 '' 和 NULL 在 CASE 里表现一样，其实完全不同。
-
CASE WHEN col = '' THEN 'empty' END—— 永远匹配不到NULL，因为NULL = ''结果是UNKNOWN，不是TRUE - 要同时捕获空值和空字符串，得显式写：
CASE WHEN col IS NULL OR TRIM(col) = '' THEN 'missing' ... END - 注意
TRIM()在不同数据库行为略有差异（如 SQL Server 默认不删制表符），生产环境建议统一用NULLIF(TRIM(col), '')先转成NULL，再统一判断 - 如果源字段是
TEXT或超长字符串，TRIM+= ''可能比IS NULL慢一个数量级，高频查询中建议加函数索引（如 PostgreSQL 的CREATE INDEX ON t ((NULLIF(TRIM(col), '')))）
CASE WHEN 真正难的不是语法，而是它把业务逻辑硬塞进 SQL 层后，会让边界条件（尤其是 NULL、空值、类型隐式转换）变得极难追踪。上线前务必用真实数据覆盖所有分支，别只测主流程。
