存储过程中的CASE WHEN必须用搜索式写法并以END CASE结尾，不支持简单式、穿透行为及复杂语句；每个WHEN分支多语句需BEGIN...END包裹，ELSE为必需兜底项，条件顺序决定执行路径。
CASE WHEN 在存储过程中必须用搜索式写法（CASE WHEN condition THEN ...），简单式（CASE col WHEN val THEN ...）只适用于等值映射，90%的业务分支都得靠前者。
存储过程里 CASE WHEN 必须带 END CASE
MySQL 存储过程中的 CASE 是流程控制语句，不是表达式，结尾必须写 END CASE，漏掉会直接报错 ERROR 1064。它和 SELECT 里的 CASE ... END 不同，后者是表达式语法，而存储过程里是语句块，有明确的开始与结束边界。
-
CASE后不能跟分号，WHEN和THEN之间不能换行写条件（虽然语法允许，但易读性差，且某些客户端会截断） - 每个
WHEN分支后的语句如果不止一条，需用BEGIN ... END包裹，例如SET @a = 1; INSERT INTO log VALUES (@a); -
ELSE不是可选的“锦上添花”，而是兜底必需项：没写ELSE且所有条件都不满足时，MySQL 会抛出ERROR 1339 (42000): Case not found for CASE statement
CASE WHEN 条件顺序影响结果，且不支持“穿透”
存储过程中的 CASE WHEN 按书写顺序逐条求值，遇到第一个为 TRUE 的条件就执行对应 THEN 后的语句，并立即退出整个 CASE 块——后续 WHEN 不再检查。这和 switch-case 的 break 隐含行为一致，但容易被忽略的是：它不支持 fall-through（即没有类似 C 语言中省略 break 导致的穿透）。
- 常见错误：把区间写反，比如先写
WHEN salary 再写 <code>WHEN salary ，后者永远不触发 - 数值区间建议从高到低或从低到高统一排序，例如工资分级应写成
salary → <code>salary → <code>salary ，避免逻辑缺口 - NULL 判断要显式写出：
WHEN salary IS NULL THEN ...，不能依赖= NULL（永远为 false）
在 SET 或 SELECT 中混用 CASE 表达式要小心类型隐式转换
当在存储过程里用 CASE 给变量赋值（如 SET res = CASE WHEN ...）或直接 SELECT CASE ... 返回结果时，MySQL 会对所有 THEN 和 ELSE 分支的返回值做类型推导。一旦分支返回类型不一致（比如有的返回字符串，有的返回整数），MySQL 会尝试隐式转换，可能造成截断或科学计数法输出。
- 例如：
SET res = CASE WHEN id = 1 THEN 'active' ELSE 0 END;，此时res被推导为 DECIMAL，'active'会转成0，而不是报错 - 解决方法：统一用字符串，或显式
CAST(... AS CHAR)，或把数字分支也写成字符串：ELSE '0' - 调试技巧：在开发阶段加一句
SELECT CONCAT('type:', TYPEOF(res));（需 MySQL 8.0.30+）或用SELECT res, LENGTH(res), res + 0;快速验证实际类型
别在 CASE WHEN 里调用耗时函数或子查询
存储过程的 CASE WHEN 是同步执行的，每个 WHEN 条件都会被完整求值（即使前面已匹配）。如果某个 WHEN 里写了 (SELECT COUNT(*) FROM huge_table WHERE ...) 或 SLEEP(1)，那它一定会被执行，不管是否最终被选中。
- 性能陷阱：看似“短路”的逻辑，实际没有短路——MySQL 不会跳过未命中分支的条件计算
- 正确做法：把复杂判断提前算好，存入局部变量，再在
CASE中做轻量比较，例如先SELECT COUNT(*) INTO @cnt FROM t3 WHERE ...;，再WHEN @cnt > 0 THEN ... - 更安全的替代：对多条件、多查询场景，优先考虑用多个独立的
IF ... ELSEIF ... END IF，它天然支持条件短路，语义也更清晰
最常被忽略的一点是：存储过程里的 CASE 不支持在 WHEN 子句中使用游标、异常处理或其它流程控制语句——它只接受纯布尔表达式。一旦需要动态 SQL 或上下文感知逻辑，就得切回 IF 或拆成多个小过程。
