MySQL中CASE WHEN有简单和搜索两种形式，需严格写END、显式处理NULL、避免子查询和函数导致索引失效，返回值字符集应统一，多枚举值建议用维表。
MySQL中CASE WHEN的基本写法和常见错误
直接用 CASE WHEN 做字段值映射是安全且高效的，但新手常在语法结构上出错：漏写 END、混淆 WHEN 后的比较逻辑（比如误写成 WHEN status = '1' 却没加引号导致隐式转换）、或把 ELSE 写成 ELSE NULL 却忘了加 END。MySQL 不会报语法错，但结果可能全为 NULL 或意外匹配。
正确结构只有两种：CASE value WHEN compare_value THEN result（简单形式），或更常用的 CASE WHEN condition THEN result（搜索形式）。业务枚举转换几乎都用后者，因为条件更灵活。
- 字段值是数字但需转中文描述时，用
WHEN status = 1 THEN '待审核' - 字段是字符串但有大小写/空格不一致时，先用
TRIM(UPPER(status))统一再判断 - 避免在
WHEN中写子查询——性能差且 MySQL 8.0 以前不支持 - 所有分支返回类型最好一致，否则 MySQL 可能强制转成字符串，影响排序或数值计算
处理NULL和默认值的惯用写法
业务字段经常存 NULL，而前端又不能显示空，这时候靠 ELSE 不够可靠——如果漏写 ELSE，NULL 输入会直接变 NULL 输出，而不是你期望的“未知”或“未设置”。必须显式覆盖。
更麻烦的是，有些枚举字段本身允许 NULL，但业务上它和某个具体值（如 0）含义不同，不能一并塞进同一个 WHEN 分支。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 显式判断
WHEN status IS NULL THEN '未填写'，别依赖ELSE捕获 -
ELSE只用于兜底“其他所有未列明的值”，建议固定写成ELSE '其他'或抛异常（用ELT(0, ...)不现实，就老实用字符串） - 如果字段定义为
TINYINT NOT NULL DEFAULT 0，但0实际代表“无效”，那就得单独写WHEN status = 0 THEN '无效'，不能指望ELSE替你区分
在JOIN或WHERE中复用CASE结果的技巧
不能直接在 WHERE 或 ON 里写 CASE WHEN status = 1 THEN '待审核' END = '待审核'——这等于重复计算，且无法走索引。想按转换后的语义过滤，得换思路。
要么把 CASE 提到子查询里生成临时列，再在外层查；要么改用原始字段条件。前者可读性好，后者性能好。没有银弹，得看场景。
- 要查“所有显示为‘已通过’的记录”，优先写
WHERE status = 2（假设 2 是通过码），而不是靠CASE转完再筛 - 真需要按转换后结果聚合（比如统计各状态中文名的数量），就用
SELECT ..., CASE WHEN ... END AS status_label FROM t GROUP BY status_label——MySQL 允许GROUP BY引用SELECT列别名 - 在
ORDER BY里可以用别名，但WHERE不行；想按中文名排序又不想改业务逻辑？只能用ORDER BY CASE WHEN status = 1 THEN 1 WHEN status = 2 THEN 2 ELSE 99 END
性能和字符集容易被忽略的细节
CASE WHEN 本身不拖慢查询，但嵌套过深或条件里调用函数（比如 WHEN DATE(created_at) = '2024-01-01'）会导致索引失效。另外，返回值字符集若与连接默认字符集不一致，可能触发隐式转换，查出来乱码或比较失败。
- 每个
THEN后的字符串字面量，最好显式声明字符集，比如THEN _utf8mb4'待审核'，尤其当表用utf8mb4而客户端连的是latin1时 - 避免在
CASE里做耗时操作：不调SUBSTRING_INDEX、不嵌(SELECT ...)、不用JSON_EXTRACT解析大字段 - 如果枚举值很多（超过 10 个），考虑建维表关联，比长
CASE更易维护；但单次查询少于几万行，CASE依然更快
最常被跳过的其实是测试边界：比如状态字段突然新增了服务端没同步的值，CASE 里没覆盖，结果全进了 ELSE，线上看到一堆“其他”，却没人知道是漏配置还是数据异常。
