SQL视图无法直接用ENUM类型JOIN，必须通过映射表实现枚举码值到可读名的转换；需LEFT JOIN映射表并用COALESCE处理缺失值，注意ON中过滤type、避免WHERE误转内连接、索引优化及缓存更新问题。
SQL视图里不能直接用 ENUM 类型做 JOIN，得靠映射表
MySQL 或 PostgreSQL 的视图本身不支持运行时枚举值解析；所谓“枚举转换”，本质是把数字/字符串码值查成可读名，必须依赖额外的映射表（Mapping Table）。硬写 CASE WHEN 看似快，但一改枚举定义就要改视图，维护成本爆炸。
典型错误现象：Unknown column 'status_name' in field list —— 因为没在视图里显式关联映射表，只写了原始字段。
- 映射表结构建议至少含三列：
code（业务码，如'ACTIVE'或1）、label（展示名，如'启用'）、type（区分是user_status还是order_type，方便复用） - 视图中必须用
LEFT JOIN关联映射表，避免因码值异常（如空、不存在）导致整行丢失 - 如果原始字段是数字型（如
tinyint），映射表的code列也得是数字类型，否则隐式转换可能走错索引或漏匹配
PostgreSQL 中用 JOIN + COALESCE 处理缺失映射
PostgreSQL 对 NULL 更敏感，直接 JOIN 可能丢数据。推荐用 COALESCE fallback 到原始码值，兼顾可读性与健壮性。
CREATE VIEW user_view AS
SELECT
u.id,
u.status_code,
COALESCE(m.label, CONCAT('UNKNOWN(', u.status_code, ')')) AS status_name
FROM users u
LEFT JOIN code_mapping m
ON m.code = u.status_code
AND m.type = 'user_status';
注意：m.type = 'user_status' 必须写进 ON 条件，不能放 WHERE，否则 LEFT JOIN 退化为 INNER JOIN。
- 如果映射表有复合主键（如
(type, code)），记得建联合索引，否则 JOIN 性能骤降 - 不要在视图里用
USING简写，容易和同名字段混淆，显式写ON更可控 -
COALESCE第二参数建议带上下文（如'UNKNOWN(status: ... )'），比纯u.status_code更利于排查
MySQL 视图中避免 GROUP BY 隐式依赖映射表字段
MySQL 5.7+ 默认开启 sql_mode=ONLY_FULL_GROUP_BY，一旦视图里用了 GROUP BY 却没把映射表字段包含进去，就会报错：Expression #2 of SELECT list is not in GROUP BY clause。
- 解决方案不是关 SQL mode，而是确保所有非聚合字段都来自同一张表，或显式写进
GROUP BY—— 比如GROUP BY u.id, m.label - 如果只是想去重展示状态名，别在视图里做
GROUP BY，放到上层查询处理更灵活 - MySQL 对
LEFT JOIN后的WHERE m.code IS NOT NULL会自动转成内连接，真要过滤必须写成AND m.code IS NOT NULL放在ON子句里
映射表更新后视图不会自动刷新，得手动干预
这是最容易被忽略的一点：视图只是保存了查询语句，不缓存结果。但应用层如果做了结果缓存（比如 MyBatis 的二级缓存、Redis 存了视图查询结果），或者前端页面静态渲染了旧 label，就完全感知不到映射表已更新。
- 上线新枚举项前，务必检查是否涉及缓存穿透 —— 建议在映射表加
updated_at字段，缓存 key 中带上最大更新时间戳 - 开发环境可加触发器或定时任务，当
code_mapping变更时发通知，提醒测试视图逻辑 - 禁止直接
TRUNCATE code_mapping，要用事务包裹插入+删除，否则视图查询中途可能查到空状态
