MySQL存储过程中的IF-ELSE分支须用过程式语句IF...THEN...ELSE...END IF;，不可与IF()函数混淆；条件需为布尔表达式，空值须用IS NULL显式判断；每行末及END IF后均需分号；嵌套时勿漏内层END IF；浮点比较宜用ABS(a-b)。
MySQL存储过程里怎么写IF-ELSE分支
直接用 IF ... THEN ... ELSE ... END IF;，不是SQL标准里的那种表达式语法，而是过程式语句，必须成对出现、必须写在存储过程或函数体内。
常见错误是把 IF() 函数（三元表达式）和过程控制语句搞混——前者只能返回值，不能执行多条语句；后者才能做逻辑跳转、调用其他语句、嵌套循环等。
-
IF后面的条件必须是布尔表达式，不支持空值直接判等，IS NULL要显式写 - 每个分支末尾都要用分号结束，
END IF;也要加分号（注意：这是MySQL存储过程语法要求，不是可选） - 嵌套
IF时，别漏掉内层的END IF;，否则报错ERROR 1064 (42000) - 条件中避免直接比较浮点字段，建议用
ABS(a - b) 替代 <code>a = b
CASE在存储过程中该用CASE语句还是CASE表达式
两者语法不同、用途不同：过程体里要控制流程（比如根据状态插入不同表），必须用 CASE ... WHEN ... THEN ... ELSE ... END CASE;；如果只是给某个字段赋一个动态值（如 SET @level = CASE score WHEN ... END;），才用表达式形式。
容易踩的坑是误把表达式当语句用——比如写 CASE status WHEN 'A' THEN INSERT ... END;，这会直接报语法错误，因为表达式不能执行语句。
- 过程式
CASE支持WHEN condition THEN statement_list，statement_list可以是多条语句，用分号分隔 - 表达式式
CASE必须有返回值，且所有分支返回类型需兼容，否则隐式转换可能出错（比如混合INT和VARCHAR） - 过程式
CASE的ELSE分支不是必须的，但没写又没匹配到任何WHEN，会报ERROR 1339 (42000): Case not found for CASE statement
IF和CASE哪个性能更好、什么时候该换用
纯计算场景下几乎没有差别；但涉及大量分支跳转、尤其嵌套深或条件复杂时，CASE 语句通常比多层 IF 更易读、更少缩进混乱，MySQL优化器对两者的处理也基本一致。
真正影响性能的是条件本身的开销——比如每个 WHEN 都查一次子查询，或者 IF 里反复调用函数，而不是语法选择本身。
- 简单二选一分支（如状态开关），
IF更直白 - 多个离散值判断（如 status IN ('A','B','C','D')），
CASE更紧凑，也更容易加注释说明每种取值含义 - 条件含范围判断（如
score BETWEEN 90 AND 100），优先用IF，因为CASE表达式不支持范围，过程式CASE的WHEN只接受布尔表达式，写起来反而啰嗦
调试存储过程中的IF/CASE分支不生效怎么办
最常被忽略的是变量作用域和初始化问题：未声明或未赋值的变量默认为 NULL，而 NULL = 'X' 结果是 NULL（非真非假），导致所有 IF 或 WHEN 分支都跳过。
别依赖客户端工具的“执行成功”提示——它只表示语法通过，不保证逻辑走对了分支。必须用 SELECT 或 INSERT INTO debug_log 打点验证实际进入哪条路径。
- 在每个
THEN块开头加SELECT 'in branch A';快速定位执行流 - 检查变量是否用
DECLARE正确定义，且类型匹配（比如把VARCHAR值赋给INT变量，会静默截断或转成0） - 注意字符集和排序规则：比较中文或带空格字符串时，
'a ' = 'a'在某些 collation 下可能为真，引发意外分支
实际写的时候，逻辑越靠近业务含义，越容易漏掉边界情况——比如状态字段突然新增一个值，但 CASE 没补 ELSE，过程就中断。宁可多写一行 ELSE BEGIN ... END; 记个日志，也别让分支失控。
