很多人写 MySQL 存储过程时，明明 `SELECT` 里的 `IF()` 用得很顺，一到过程里改成条件分支就开始报错。问题通常不在“会不会写判断”，而在于 MySQL 把存储过程里的 IF 当作流程控制语句处理：它有固定出现位置、严格的结束结构，还会受到 DELIMITER、NULL 判断和精度比较的影响。
这篇文章按“先判断能不能写，再判断怎么写对”的顺序整理重点。你可以直接对照语法结构、分支规则和常见错误码检查自己的过程定义，快速定位是结构问题、条件问题，还是比较方式本身不稳。
IF 先看位置：它只能写在 BEGIN ... END 里
MySQL 存储过程里的 IF 是过程式语句，不是函数。它只能出现在 BEGIN ... END 代码块内，不能直接塞进普通查询或视图定义里。
标准结构如下：
IF condition THEN
...
ELSEIF condition THEN
...
ELSE
...
END IF;
这里有几个必须同时满足的语法要求：
END IF;必须完整写出，不能写成ENDIF或ENDIF;- 每个分支里的语句末尾都要有分号，例如
SET @x = 1;、SELECT 'ok'; - 嵌套判断时，每一层都要有各自的
END IF;，少一层都会直接触发语法错误
这也是很多 ERROR 1064 的来源：不是条件表达式错了，而是结构没有闭合，或者分号让 MySQL 提前结束了语句。
定义存储过程前，别漏掉 DELIMITER
另一个高频问题是没有先改分隔符。因为存储过程内部本来就有大量 ;，如果还使用默认分隔符，MySQL 会在 CREATE PROCEDURE 还没结束时就提前截断语句，导致整个过程无法创建。
常见写法如下：
DELIMITER //
CREATE PROCEDURE demo_proc()
BEGIN
IF 1 = 1 THEN
SELECT 'ok';
END IF;
END //
DELIMITER ;
别把过程式 IF 和 IF() 函数混用
很多报错都来自这个混淆：存储过程里的 IF 用来控制流程，而 IF(status=1, 'Y', 'N') 这种写法是表达式函数，用来返回值。
两者用途不同：
- 过程式
IF ... THEN ... END IF;：控制执行哪一段语句 - 函数式
IF(expr, v1, v2)：通常用于SELECT或SET中返回结果
也就是说，下面这种表达式函数不能替代流程控制：
IF(status=1, 'Y', 'N')
它适合放进查询或赋值语句里，但不能拿来决定一段 SQL 是否执行。
多分支和 NULL 判断，都是常见语法坑
多分支必须写 ELSEIF，不能拆开写
MySQL 不支持 ELIF，也不接受带空格的 ELSE IF 作为同一层分支关键字。正确写法只能是 ELSEIF，并且整组分支共用一个 END IF;。
- 正确：
ELSEIF @status = 2 THEN ... - 错误：
ELIF @status = 2 THEN ... - 错误：
ELSE IF @status = 2 THEN ...
ELSE IF 在 MySQL 里会被解析成 ELSE 后又开启一个独立的 IF，结果不是单纯“写法不优雅”，而是结构和逻辑都会变乱。
条件里遇到 NULL，必须用 IS NULL
在 MySQL 的三值逻辑里，= NULL 不会按你预期工作。判断空值时，必须显式使用 IS NULL 或 IS NOT NULL。
- 错误写法：
IF @val = NULL THEN ... - 正确写法：
IF @val IS NULL THEN ... - 正确写法：
IF @val IS NOT NULL THEN ...
多个条件组合时，AND 和 OR 的优先级也容易造成误判。更稳妥的方式是直接加括号：
IF (@a > 0 AND @b IS NOT NULL) THEN ...
这样做的好处不是“更好看”，而是避免复杂条件在维护时被误读。
浮点和字符串比较，别直接照抄整数判断思路
浮点值比较建议用误差范围
如果存储过程里的变量是 DECIMAL，或者来自计算结果的浮点值，直接用 = 往往不稳，原因是精度丢失后看起来相等、实际不完全相同。
更安全的写法是给出允许误差：
IF ABS(@a - @b) < 0.0001 THEN ...
如果业务上本来就只关心固定小数位，也可以先转成整数语义后再比较：
IF ROUND(@a * 100) = ROUND(@b * 100) THEN ...
字符串比较最好先统一格式
字符串判断除了值本身，还会受大小写和前后空格影响。为了减少脏数据带来的误判，可以先做标准化：
TRIM(UPPER(@str)) = 'YES'
这种写法尤其适合处理外部输入值，能减少因为空格或大小写不一致导致的分支偏差。
为什么会报 ERROR 1064 和 ERROR 1339
如果你的存储过程里出现 ERROR 1064 或 ERROR 1339，通常可以优先从下面几个点排查：
IF是否真的写在BEGIN ... END里面END IF;是否完整闭合，分支里的语句是否都带分号ELSEIF是否误写成ELIF或ELSE IFNULL是否被写成= NULL- 过程定义前是否已正确设置
DELIMITER - 多分支逻辑是否缺少兜底的
ELSE
原文特别提到：如果所有条件都不匹配，又没有写 ELSE，运行时可能报 ERROR 1339 (42000): Case not found for CASE statement。这个错误名看起来像是 CASE 的问题，但在实际排查时，也应顺手检查当前分支结构是否缺少兜底逻辑。
归纳来看，MySQL 存储过程里的 IF 难点不在语义本身，而在它对结构和细节非常敏感。只要先守住“出现位置正确、结构闭合完整、比较方式合适”这三条主线，绝大多数判断分支都能一次写通。
