应优先使用简单case进行等值匹配，如状态码映射；搜索case适用于范围判断等复杂条件，且必须按优先级从高到低排列条件，因case逐行匹配首个true分支即返回结果，顺序错误会导致逻辑偏差。
CASE 在 SELECT 语句里不是“显示逻辑”，而是**生成新列值的表达式**——它不控制界面渲染，只决定查询结果中某列输出什么内容。
什么时候该用简单 CASE 而不是搜索 CASE？
当你在做「等值匹配」时，比如把状态码 status 的 'A' 映射为 '激活'、'I' 映射为 '停用'，就该用简单 CASE：
- 语法更短，可读性高；
- MySQL 会内部优化成哈希查找（小范围值时性能略好）；
- 但只能写
CASE column WHEN value THEN ...，不能加运算符或函数。
错误示范：CASE status WHEN UPPER('a') THEN '激活' —— UPPER() 不合法，简单 CASE 只允许字面量或列名直接比较。
搜索 CASE 中条件顺序为什么关键？
CASE WHEN 是从上到下逐条判断，**第一个为 TRUE 的分支就返回结果，后续不管是否也满足，全跳过**。这直接影响分级逻辑是否准确。
- 比如成绩分级：必须写
WHEN score >= 90在前，WHEN score >= 80在后；反过来会导致所有 ≥90 的人被错判为“良好”； - 范围重叠时（如
score > 60和score >= 60），后者永远不可达； - NULL 值不会命中任何
WHEN（哪怕写score = NULL也不行），必须靠ELSE捕获。
SELECT 中用 CASE 时容易忽略的数据类型问题
CASE 所有 THEN 和 ELSE 分支返回的值，最终会被 MySQL 隐式转成同一类型。一旦类型不一致，可能引发截断、精度丢失或隐式转换开销。
- 例如：
CASE WHEN flag THEN 1 ELSE 'N/A'→ MySQL 会把1转成字符串'1'，或把'N/A'转成数字0（取决于上下文），结果不可控； - 安全做法：统一显式类型，比如都用
CAST(... AS CHAR)或都用数值型； - 聚合场景下尤其危险：
SUM(CASE WHEN paid THEN amount ELSE 0 END)比SUM(CASE WHEN paid THEN amount ELSE NULL END)更稳——后者会让整行求和变NULL。
别把 CASE 当万能胶，该用 WHERE 就别硬塞进去
CASE 是表达式，不是过滤器。它适合“分类展示”，不适合“筛选数据”。
- 想查“只看女员工”，写
WHERE gender = 'F'，而不是SELECT ..., CASE WHEN gender='F' THEN name END—— 后者仍返回所有行，只是男员工的name变成NULL； - 在
ORDER BY或GROUP BY里嵌套复杂CASE，可能让索引失效，特别是含函数或子查询时； - 如果只是做二值映射（如
IF(status='A', '是', '否')），IF()比CASE更轻量，少写几个字。
真正难的不是写对语法，而是判断该不该用——CASE 解决的是“同一字段多态输出”，不是“要不要这条记录”。
