视图中case when只能作为select列表中的表达式且必须带as别名；不可用于where、from等位置，漏else会导致null静默传导，类型不一致引发隐式转换问题，多分支应改用映射表join替代。
视图里只能把CASE WHEN当SELECT表达式用
SQL视图本质是保存的SELECT语句，不支持流程控制，所以CASE WHEN不能出现在WHERE、FROM或独立成行的位置。它必须作为SELECT列表中的一列，且必须带AS别名，否则数据库直接报错，错误提示往往模糊（比如“column not found”或“syntax error near CASE”）。
常见翻车点：
- 在
WHERE里写CASE WHEN type = 'U' THEN user_id ELSE admin_id END = 123——语法虽过，但索引基本失效，查询变慢 - 在
FROM后直接写CASE WHEN ... END却不加AS——数据库无法识别这是计算列还是语法碎片，报错位置难定位 - 想靠
CASE控制某行是否被返回（比如只留已审核订单）——该用WHERE audit_status = 'approved'，不是CASE
必须显式写ELSE，且所有THEN分支类型要一致
漏ELSE不是语法错误，而是逻辑陷阱：不满足任何WHEN条件时，整列返回NULL。这个NULL会静默传导到下游应用，比如前端显示为空、报表统计少计数、聚合函数（如SUM）跳过该行——问题暴露时往往已上线多日。
类型不一致更隐蔽：
- PostgreSQL 会直接报错：
ERROR: CASE types text and integer cannot be matched - MySQL 会静默转成字符串，导致
COUNT()还能用，但AVG()返回0，ORDER BY按字典序排 - 示例错误写法：
CASE WHEN flag = 1 THEN 100 ELSE 'N/A' END→ 整列变成VARCHAR
正确做法：统一用字符串（THEN '100' ELSE 'N/A'）或统一用数字（THEN 100 ELSE -1），避免隐式转换。
5个以上WHEN分支就该考虑映射表JOIN
视图里堆10个WHEN分支，不只是难读，还会拖慢查询：每个分支都要逐行计算，优化器无法下推条件，大表上容易退化成全表扫描。更麻烦的是维护——业务规则一变，就得改视图定义，还可能牵连多个报表。
替代方案更稳：
- 建一张映射表，比如
status_mapping(status_code, label, priority)，主键或唯一索引确保status_code不重复 - 视图里用
LEFT JOIN status_mapping ON t.status = status_mapping.status_code，再COALESCE(status_mapping.label, '未知')兜底 - 映射表可单独管理、加注释、配权限，甚至接低代码后台动态维护
这种写法对查询性能更友好：JOIN能走索引，逻辑也从“硬编码分支”变成“数据驱动”，后续加新状态只需插一行数据，不用动SQL。
GROUP BY和聚合里用CASE必须完全复现逻辑
在视图里做分组统计时，SELECT里的CASE WHEN和GROUP BY里的表达式必须字面一致，否则MySQL 8.0+严格模式下直接报错：ERROR 1055；即使兼容模式跑通，结果也可能错位（比如把“under_18”和“Under_18”分到两组）。
安全写法要点：
-
GROUP BY里不能写别名，必须复制粘贴SELECT中完整的CASE块 - 字符串类判断前加
TRIM(UPPER())，避免空格或大小写导致分组分裂 - 涉及时间范围时，用
DATE(created_at)或YEARWEEK(created_at)等确定性函数，别用NOW()这类运行时变量（视图定义固化，不能每次查都动态算）
真正容易被忽略的是：视图一旦定义，里面所有表达式就固化了。你今天写的CASE WHEN age BETWEEN 18 AND 35，三年后用户年龄增长，逻辑不会自动更新——它不是活的业务规则引擎，只是快照。复杂分支务必抽成映射表，留给业务方自己维护。
