应使用CASE WHEN在视图中直接映射状态值，如CASE order_status WHEN 0 THEN '待支付' WHEN 1 THEN '已发货' WHEN 2 THEN '已完成' ELSE '未知状态' END AS status_name，必须加ELSE兜底防NULL，避免数据丢失。
直接用 CASE WHEN 构建状态映射视图，别绕弯
SQL 中没有“状态映射类型”，但 CASE WHEN 是最可靠、最通用的实现方式。只要字段值有限且可枚举（比如订单状态码 0/1/2），就该用它——不依赖扩展函数，兼容 MySQL、PostgreSQL、SQL Server、Oracle 全部主流引擎。
写法必须加 ELSE，否则 NULL 会悄悄吞掉数据
漏写 ELSE 是高频翻车点：当源字段出现未覆盖的值（比如新增了状态 99），整行对应列返回 NULL，而你可能根本没意识到数据丢了。
实操建议：
- 显式写
ELSE 'UNKNOWN'或ELSE 'UNEXPECTED_' || status_code（PostgreSQL/MySQL 8.0+ 支持） - 上线前用
WHERE status_code NOT IN (0,1,2)扫一遍，确认无遗漏值 - 如果业务要求严格禁止未知状态，
ELSE NULL反而是正确选择，但得配合应用层校验
避免在 WHERE 中重复写 CASE 表达式
有人习惯这样过滤：WHERE CASE WHEN status = 0 THEN 'draft' WHEN status = 1 THEN 'paid' END = 'paid'——性能差、不可索引、难维护。
正确做法是：
- 先在
SELECT里定义别名，如CASE WHEN status = 1 THEN 'paid' END AS status_label - 过滤时用原始字段：
WHERE status = 1，而不是WHERE status_label = 'paid' - 若真需按标签过滤（比如前端传的是中文），把映射逻辑下推到子查询或 CTE，避免外层重复计算
字符串拼接和类型隐式转换是隐形坑
CASE WHEN 各分支返回类型不一致时，数据库会强制转成统一类型，可能导致截断或精度丢失：
- MySQL 中
WHEN 1 THEN 'active' ELSE 0→ 全转为字符串，0变成'0'，但长度可能被截短 - PostgreSQL 更严格，直接报错：
ERROR: CASE types character varying and integer cannot be matched - 安全写法：所有分支显式转成同一类型，比如都用
CAST(... AS TEXT)或都用TO_CHAR()
复杂映射别硬塞进单层 CASE；超过 5 种状态就该考虑用关联维表，或者把映射规则抽到配置表里——CASE 是快刀，不是万能胶。
