MySQL中CASE是表达式而非独立语句，必须嵌入SELECT、UPDATE等语句中；分简单和搜索式两种语法，推荐后者；需注意类型一致性、ELSE缺失风险、索引失效及避免替代WHERE。
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。
