最稳妥通用的状态码映射方式是CASE WHEN，必须包含ELSE分支防NULL，注意状态值类型一致、显式处理NULL、避免WHERE中过滤计算字段。
用 CASE WHEN 实现状态码到业务文本的映射
直接在 SELECT 列表里做状态翻译，最稳妥、最通用的方式就是 CASE WHEN。它不依赖数据库方言，语义清晰，且能精确控制每个状态值的输出文本。
常见错误是漏写 ELSE 分支——一旦遇到未覆盖的状态码（比如新上线的状态或脏数据），结果列会变成 NULL，前端可能直接显示为空白，排查困难。
CASE WHEN status = 0 THEN '待提交' WHEN status = 1 THEN '已审核' WHEN status = 2 THEN '已驳回' ELSE '未知状态' END AS status_text- 状态值类型要一致：如果
status是字符串（如'PENDING'），条件里也得用字符串匹配，不能写成WHEN status = 0 - 多个相同分支可合并：
WHEN status IN (3,4) THEN '已关闭'
用 MySQL 的 ELT() 或 PostgreSQL 的 CASE 简化短列表
当状态码是连续小整数（如 0/1/2/3），且顺序固定，MySQL 可用 ELT() 缩短写法；PostgreSQL 则推荐继续用 CASE，因为 ELT() 是 MySQL 特有函数，跨库迁移时容易出错。
注意 ELT() 的索引从 1 开始，不是 0 —— 这是高频翻车点：
- 错误写法：
ELT(status, '待提交', '已审核', '已驳回')→ 当status = 0时返回NULL，不是第一个值 - 正确写法：
ELT(status + 1, '待提交', '已审核', '已驳回')，前提是status为 0/1/2 - 更安全的做法仍是
CASE，尤其当状态码存在空缺（如只有 0/2/5）时，ELT()完全不可用
避免用 JOIN 关联字典表“过度设计”
有人习惯为状态建一张 sys_status 表，再在查询里 LEFT JOIN。这在需要复用描述、支持多语言或频繁变更文案时合理；但若只是单个查询临时翻译，JOIN 带来额外 I/O 和连接开销，还可能因关联失败导致整行丢失（用 INNER JOIN 时）。
- 纯翻译场景下，
CASE性能更好、逻辑更内聚 - 如果状态文本本身存在数据库中（比如需后台编辑），才考虑字典表，此时务必加
LEFT JOIN+COALESCE(t2.name, '未知') - 别在
WHERE中对CASE结果过滤（如WHERE status_text = '已审核'）——多数数据库无法走索引，应改写为原字段条件：WHERE status = 1
警惕 NULL、空字符串和隐式类型转换
状态字段本身可能是 NULL，或者被错误存为 ''（空字符串）。直接用 CASE WHEN status = 1 不会匹配 NULL，必须显式判断：
- 写全边界：
CASE WHEN status IS NULL THEN '无状态' WHEN status = 0 THEN '待提交' ... END - 如果字段定义为
VARCHAR但存了数字字符（如'1'），比较时用status = '1'，而非status = 1（后者触发隐式转换，在某些数据库中可能失效或慢） - Oracle 用户注意：
CASE表达式所有分支返回类型必须一致，'待提交'和NULL混用时，建议统一写成CAST(NULL AS VARCHAR2(10))避免报错ORA-00932
ELSE、漏判 NULL 或类型不一致，导致下游展示异常。与其后期追查，不如在写第一行 CASE 时就默认补上兜底分支。 
