MySQL 中 CASE
语句必须写在 SELECT
或 UPDATE
里
单独执行
CASE WHEN ... END会报错，它不是独立语句，而是表达式。常见误用是把它当存储过程里的控制流写法，结果提示
ERROR 1064。 只能嵌入在
SELECT（生成计算列）、
UPDATE（条件更新）、
INSERT ... SELECT、
ORDER BY或
HAVING中 两种语法：简单
CASE column WHEN value THEN ...和搜索式
CASE WHEN condition THEN ...，后者更常用也更灵活 所有
THEN返回值类型应尽量一致，否则 MySQL 会隐式转换，可能引发截断或精度丢失（比如混用字符串和数字）
CASE
在 SELECT
中做动态分类时要注意 ELSE
缺失风险
漏写
ELSE不报错，但不满足任何条件的行会返回
NULL，容易造成统计偏差——比如想按订单金额分「高/中/低」三档，却有一批
amount = 0的记录被悄悄归为
NULL档。 显式写
ELSE 'other'或
ELSE 0是防御性写法 如果业务上确实不允许“意外值”，可用
ELSE CAST('invalid' AS CHAR) 配合后续检查
在聚合场景中（如 SUM(CASE WHEN status='paid' THEN 1 ELSE 0 END)），
ELSE 0几乎是必须的，否则
SUM会跳过
NULL
用 CASE
实现条件更新要避免全表扫描陷阱
UPDATE orders SET status = CASE WHEN paid_at IS NOT NULL THEN 'done' ELSE 'pending' END;看似简洁，但没加
WHERE就会更新全表，即使多数行状态本就不变。 务必搭配
WHERE限定范围，例如
WHERE status != 'done' AND paid_at IS NOT NULL注意
CASE内部条件是否能命中索引：用
paid_at IS NOT NULL通常走不了索引，换成
paid_at > '1970-01-01'可能更友好（取决于字段是否允许 NULL） 多分支更新时，每个
WHEN条件尽量复用已有索引字段，避免在
CASE中调用函数（如
DATE(paid_at)）导致索引失效
CASE
不能替代 WHERE，但可配合 WHERE 做精细过滤
有人试图用
SELECT * FROM t WHERE CASE WHEN x>10 THEN 1 ELSE 0 END = 1，这完全没必要，且性能比直接写
x > 10差。CASE 的定位是“值变换”，不是“条件筛选”。 真正适合的组合是：先用
WHERE快速缩小数据集，再用
CASE对结果做分类、映射或打标 例如导出报表时，
WHERE created_at >= '2024-01-01'+
SELECT ..., CASE WHEN score>=90 THEN 'A' ...复杂判断逻辑（如多字段联合判定）放在
CASE里比塞进
WHERE更易读，但要注意 MySQL 优化器对嵌套
CASE的处理能力有限，超 5 层建议拆解
实际用多了就会发现，
CASE最容易出问题的地方不在语法，而在它掩盖了本该由索引或应用层处理的逻辑——比如用
CASE WHEN user_id IN (SELECT vip_id FROM vip_list) THEN 'vip'...，这种子查询在
CASE里会反复执行，不如提前 JOIN。
