最稳妥的状态码映射写法是：用简单case（case status when 0 then '待处理' when 1 then '已通过' else '未知状态' end as status_desc），必须显式写else防null，并强制指定有意义的别名。
CASE函数怎么写才能正确映射状态码
直接用 CASE 做状态码转换，最稳妥的方式是用简单 CASE（即 CASE column WHEN value THEN ...），而不是搜索 CASE（CASE WHEN condition THEN ...），除非状态码逻辑本身带范围或复合判断。
比如数据库里存的是数字状态码 status 字段：0=待处理、1=已通过、2=已拒绝、99=异常，想转成中文描述——这时简单 CASE 更清晰、可读性强，也更容易被优化器识别。
- 简单 CASE 要求所有
WHEN后面的值类型一致，且必须和CASE后字段类型兼容；如果status是TINYINT，就别在WHEN里写字符串'0' - 必须写
ELSE分支，否则遇到未定义状态码（比如插入了 -1）会返回NULL，线上查出来就是空值，容易漏问题 - MySQL 和 PostgreSQL 对
ELSE NULL的默认行为一致，但 SQL Server 在某些兼容模式下可能隐式转空字符串，建议显式写ELSE '未知状态'
遇到状态码是字符串或混合类型怎么办
真实业务里常出现状态字段是 VARCHAR，比如 'PENDING'、'APPROVED'，甚至混着数字和字母（'0'、'1'、'N/A'）。这时候不能硬套简单 CASE，得用搜索 CASE。
注意：不要在 WHEN 条件里做类型转换函数（如 CAST(status AS INT)），会导致索引失效；应先统一字段类型，或在应用层清洗。
- 字符串状态推荐全用大写比较，避免大小写敏感问题：
WHEN UPPER(status) = 'PENDING' THEN '待处理' - 混合类型（如既有
1又有'1'）建议先用COALESCE(NULLIF(TRIM(status), ''), '0')归一化，再进 CASE - PostgreSQL 支持
ENUM类型，比反复写 CASE 更安全；MySQL 8.0+ 也支持，但迁移成本高，临时转换还是靠 CASE 实用
为什么CASE结果字段名总变成“case”或乱码
这是 SQL 标准行为：当 CASE 表达式没指定别名时，数据库会自动给它起个匿名名，MySQL 默认叫 case，SQL Server 叫 (No column name)，导出到 Excel 或接 BI 工具时就出问题。
- 务必在
CASE表达式末尾加AS status_label（或其他有意义的别名） - 别名不能含空格或特殊字符，否则得用反引号（MySQL）或双引号（PostgreSQL）包裹：
AS "状态说明"→AS "状态说明"不推荐，改用AS status_desc - 如果用在子查询或视图中，外部查询引用该字段时，必须用你指定的别名，不能用原始字段名
性能影响：CASE太多会让查询变慢吗
单个 CASE 几乎无开销，但嵌套过深（>5 层）或在 JOIN 条件、WHERE 中大量使用，会影响执行计划选择，尤其在老版本 MySQL（5.7 及之前）里可能抑制索引下推。
- 避免在
WHERE子句里用CASE做过滤，比如WHERE CASE WHEN status=1 THEN 1 ELSE 0 END = 1—— 直接写WHERE status = 1更高效 - 如果状态码映射关系复杂且固定（比如几十种），考虑建一张
status_map码表，用LEFT JOIN替代长 CASE，方便维护也利于统计分析 - Oracle 用户注意：
CASE在函数索引里可用，但 MySQL 的函数索引不支持CASE表达式，别白费劲建
ELSE 没写，或者忘了加 AS，导出报表时整列空白，排查起来反而比逻辑重构还耗时间。
