case when视图查询慢因逐行计算、无法索引、优化器难下推，分支超5–10个或数据超10万行时易退化为全表扫描；字段类型不一致引发隐式转换进一步拖慢速度。
为什么CASE WHEN视图一查就慢
因为每个 CASE WHEN 分支在查询时都要逐行计算，无法走索引，且优化器难以下推过滤条件。当分支超过 5–10 个、数据量超 10 万行时，执行计划常退化为全表扫描 + 临时表排序。更隐蔽的问题是：字段类型不一致（比如有的分支返回 VARCHAR(20)，有的返回 INT），会触发隐式转换，进一步拖慢速度。
把CASE WHEN逻辑拆进独立映射表
核心思路是把“条件→值”的硬编码逻辑，变成可索引、可维护、可 JOIN 的物理表。例如原视图中这段：
SELECT id, name,
CASE type
WHEN 'A' THEN 'Active User'
WHEN 'B' THEN 'Beta Tester'
WHEN 'C' THEN 'Cancelled'
ELSE 'Unknown'
END AS status_label
FROM users;
应替换为一张 status_map 表：
CREATE TABLE status_map (
type_code CHAR(1) PRIMARY KEY,
label VARCHAR(50) NOT NULL,
sort_order TINYINT
);
INSERT INTO status_map VALUES ('A', 'Active User', 1), ('B', 'Beta Tester', 2), ('C', 'Cancelled', 3);
- 必须给
type_code加主键或唯一索引，否则JOIN可能产生重复行 - 如果原
CASE有优先级（如多个条件匹配只取第一个），映射表需加sort_order字段，并在 JOIN 后用ROW_NUMBER() OVER (PARTITION BY ... ORDER BY sort_order)去重 - 避免用
TEXT或过长VARCHAR存 label，影响 JOIN 效率
LEFT JOIN 替代 CASE WHEN 的写法要点
改写后查询变成：
SELECT u.id, u.name, COALESCE(m.label, 'Unknown') AS status_label FROM users u LEFT JOIN status_map m ON u.type = m.type_code;
- 用
LEFT JOIN保证原CASE的ELSE行为；COALESCE处理未匹配项，比ISNULL更跨库兼容 - 不要写
INNER JOIN—— 一旦某type值在映射表里缺失，整行就会消失，和原逻辑不符 - 若映射表字段含
NULL（比如label IS NULL表示禁用），需在ON中显式排除：ON u.type = m.type_code AND m.label IS NOT NULL - MySQL 8.0+ 可考虑用
LATERAL关联动态映射（如按时间生效的规则），但多数场景没必要，反而增加复杂度
上线前必须验证的三件事
重构不是替换名字那么简单，容易漏掉语义细节：
- 检查原
CASE WHEN是否有“范围判断”（如WHEN score BETWEEN 90 AND 100）—— 映射表只支持等值，这类得保留为子查询或函数封装 - 确认所有分支返回值类型完全一致（特别是
NULL和空字符串''在不同数据库里比较行为不同） - 跑一遍
SELECT COUNT(*) FROM users u LEFT JOIN status_map m ON u.type = m.type_code WHERE m.type_code IS NULL，看有多少“脏数据”没被映射覆盖，决定是补数据还是加兜底逻辑
映射表本身很小，但 JOIN 后的结果集膨胀风险来自左表数据量和关联基数——这点比 CASE WHEN 更依赖统计信息准确性和索引有效性。
