CASE WHEN本身不慢，慢在嵌套过深、类型混用、重复计算、WHERE滥用；高效做法是单层结构、统一类型、仅作标记，逻辑提前或外置。
直接结论：CASE WHEN本身不慢，慢在写法——嵌套过深、类型混用、重复计算、WHERE里滥用，都会让执行计划崩坏；真正高效的聚合统计，是把CASE WHEN控制在单层、统一类型、只做标记，把逻辑判断提前或外置。
避免在SUM/COUNT里反复写相同表达式
常见错误现象：EXPLAIN FORMATTED显示ExpressionEvaluation耗时占比超60%，字段如date_sub(current_date, 30)在4个CASE WHEN分支里各算一遍，CPU翻倍。
- 每个
CASE WHEN分支都是独立求值，MySQL无法复用中间结果 - 把重复计算逻辑提到子查询里，主查询只做聚合，能砍掉70%以上开销
- 示例：别这么写
SUM(CASE WHEN dt >= date_sub(current_date, 30) AND status = 'paid' THEN amount ELSE 0 END) AS paid_30d,<br>SUM(CASE WHEN dt >= date_sub(current_date, 7) AND status = 'paid' THEN amount ELSE 0 END) AS paid_7d
而应先算好基准日期：SELECT SUM(CASE WHEN dt >= dt_30d AND status = 'paid' THEN amount ELSE 0 END) AS paid_30d,<br> SUM(CASE WHEN dt >= dt_7d AND status = 'paid' THEN amount ELSE 0 END) AS paid_7d<br>FROM (SELECT *, date_sub(current_date, 30) AS dt_30d, date_sub(current_date, 7) AS dt_7d FROM orders) t
所有THEN分支必须返回统一数据类型
常见错误现象：MySQL隐式转字符串（如混用'high'和100），导致后续JOIN变慢；PostgreSQL直接报错。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
CASE WHEN是表达式，返回值类型由所有THEN和ELSE分支共同决定，MySQL取“最宽类型”，可能触发全表类型转换 - 数值类统计统一用
0/1或DECIMAL，标签类统一用VARCHAR，禁止混用 - 错误写法：
CASE WHEN a > 10 THEN 1 ELSE 'N/A' END→ 正确写法：CASE WHEN a > 10 THEN 1 ELSE 0 END或CASE WHEN a > 10 THEN 'Y' ELSE 'N' END
等值映射类逻辑一律用LEFT JOIN替代
状态码转中文、用户等级打标这类场景，硬编码在CASE WHEN里既是维护噩梦，也是性能瓶颈。
- 映射表
status_map(type_code, label, sort_order)必须有主键或唯一索引，否则LEFT JOIN可能产生笛卡尔积 - 原
CASE WHEN的优先级逻辑（如多个条件同时命中只取第一个）需靠sort_order+ROW_NUMBER() OVER (PARTITION BY id ORDER BY sort_order)实现 - 正确写法：
SELECT o.order_id, COALESCE(m.label, 'Unknown') AS status_desc<br>FROM orders o<br>LEFT JOIN status_map m ON o.status = m.type_code AND m.category = 'order_status'
别在WHERE或ON里写CASE WHEN
CASE WHEN在WHERE或JOIN ON中不会被下推，会导致全表扫描后再过滤，执行计划彻底失效。
- 错误写法：
WHERE CASE WHEN region = 'CN' THEN user_id IN (SELECT id FROM vip_users) ELSE TRUE END - 正确做法：拆成两个查询用
UNION ALL，或把条件前置到子查询中过滤 - 范围判断类逻辑（如
a > 1,a > 5）必须用WHERE先筛数据，再进CASE WHEN做分类，而不是反过来
最容易被忽略的是：CASE WHEN不是万能逻辑容器，它只适合单次扫描+累加的轻量标记。一旦分支超5个、涉及多字段组合判断、或需要复用中间结果，就该立刻考虑子查询、临时表或映射表——否则优化永远在补窟窿。
