视图不能直接写业务状态转换逻辑，因其不支持运行时参数、变量或动态条件分支；硬编码值导致维护困难，多状态应使用映射表而非嵌套CASE WHEN；状态字段类型必须统一且显式处理NULL。
视图里不能直接写业务状态转换逻辑
视图不是函数，它不支持运行时参数、变量或动态条件分支。你写 CREATE VIEW user_status AS SELECT id, CASE WHEN last_login > DATE_SUB(NOW(), INTERVAL 30 DAY) THEN 'active' ELSE 'inactive' END 看似可行，但问题在于：这个“30天”是硬编码值，一旦业务要求改成“90天”或按用户等级差异化（VIP=180天，普通=30天），你就得 ALTER VIEW ——而所有依赖它的报表、BI看板、ORM模型都会瞬间失效或字段错位。
CASE WHEN 必须提前物化进基础视图，不能留到调用层再算
状态判断本身可以放视图里，但前提是它基于稳定字段、无外部依赖、类型统一。常见错误是把 CASE WHEN 塞进下游查询，导致重复计算和逻辑分散：
- 错误：每次查活跃用户都重跑
CASE WHEN last_login > '2026-06-02' THEN 'active'——日期硬写，维护成本高 - 正确：在基础视图
clean_users中固化状态字段：SELECT id, last_login, COALESCE(last_login, '1970-01-01') AS login_date, CASE WHEN last_login > DATE_SUB(CURDATE(), INTERVAL 30 DAY) THEN 'active' ELSE 'inactive' END AS status - 后续所有查询直接
SELECT * FROM clean_users WHERE status = 'active'，WHERE 条件可走索引，逻辑集中，改口径只需改视图定义
多状态嵌套转换必须用显式映射表，别堆CASE WHEN
当状态逻辑涉及多级判定（如订单：created → paid → shipped → delivered → refunded），且规则随时间变化（比如2024年退款超7天才生效，2025年起改为3天），硬写十几层 CASE WHEN 不仅难读，更难验证和回溯。真正可维护的做法是：
- 建一张
order_status_rule映射表，字段含from_status、to_status、min_days、effective_from - 视图中用
LEFT JOIN关联该表，再用CASE WHEN做最终归类，例如：CASE WHEN r.min_days IS NOT NULL AND DATEDIFF(NOW(), o.created_at) >= r.min_days THEN r.to_status ELSE o.current_status END - 规则变更只改映射表数据，不动视图 DDL；历史数据可加
effective_from时间戳做快照比对
状态字段参与 GROUP BY 或聚合时，类型必须严格一致
这是最容易被忽略的坑：你定义了 CASE WHEN ... THEN 'high' ELSE 1 END，数据库会把整列转成字符串，导致 SUM(status_score) 返回 0 或报错。真实影响包括：
-
GROUP BY status时，若 status 是混合类型，MySQL 可能静默截断，PostgreSQL 直接报错 - BI 工具读取视图元信息时，字段类型错误会导致图表维度错乱
- 正确做法：所有分支返回同类型——要标签就全用字符串（
THEN 'active'、ELSE 'inactive'）；要数值就全用整数（THEN 1、ELSE 0） - 遇到可能为 NULL 的输入字段，必须用
CASE WHEN col IS NULL THEN 'unknown' ELSE ... END，别依赖隐式= NULL判断
复杂状态逻辑的边界很清晰：视图负责固化「依据」和「静态映射」，不承担「参数驱动」或「跨时间规则切换」；真需要动态性，就得靠外层查询拼条件，或者上表值函数——但那已超出视图能力范围。
