MySQL 5.7 存储过程中必须用 IF-ELSEIF-ELSE 结构替代 CASE WHEN，且需严格连写、显式处理 NULL、避免深层嵌套、配合事务与错误处理器，并区分 IF 语句与 IF() 函数。
MySQL 5.7 的存储过程不支持 CASE WHEN 作流程控制，必须用 IF-ELSEIF-ELSE-END IF 结构；嵌套超 4 层、条件含 NULL 或浮点比较时，极易掉进语法报错或逻辑误入 ELSE 的坑。
IF-ELSEIF-ELSE 必须严格连写，空格和分号都不能错
很多人复制代码时把 ELSEIF 写成 ELSE IF（中间有空格），MySQL 直接报 ERROR 1064。这不是风格问题，是解析器硬性要求：关键字必须连写，THEN 不可省，每个分支末尾必须有 END IF;，且该行末尾也要加分号。
-
IF @a > 10 THEN SET @msg = 'big'; END IF;合法 -
ELSEIF @b = 'x' THEN INSERT ...;合法，但ELSE IF @b = 'x' THEN会报错 - 嵌套时内层也得闭合：
IF @x THEN IF @y THEN ... END IF; END IF; - 所有
END IF后必须带分号，漏掉一个就整个过程创建失败
NULL 会让整个条件变 UNKNOWN，必须显式判断
MySQL 的三值逻辑意味着：@type = 'user' 在 @type 为 NULL 时结果不是 FALSE，而是 UNKNOWN，等效于进入 ELSE 分支——这常导致本该走的逻辑被跳过。
- 错误写法：
IF @type = 'user' AND @status = 'active'→ 只要任一为NULL，整条表达式即UNKNOWN - 正确写法：
IF @type IS NOT NULL AND @type = 'user' AND @status IS NOT NULL AND @status = 'active' - 或用
COALESCE(@type, '') = 'user'，但要注意类型隐式转换风险（比如数字字段转字符串） - 多个变量联合判断时，拆成独立
IF或ELSEIF更可控，避免单条件过长
别硬堆 ELSEIF，超 4 层就该用状态码中转
MySQL 5.7+ 实际能稳定解析的嵌套层级一般不超过 8 层；再深可能触发 ERROR 1429 或服务端栈溢出。这不是理论限制，是线上真实踩过的坑。
- 推荐做法：
DECLARE status_code TINYINT DEFAULT 0;，然后用SET status_code = (SELECT ...)一次性算出分支依据（比如查配置表或业务规则表） - 后续只写一层：
IF status_code = 1 THEN ... ELSEIF status_code = 2 THEN ... - 这样既避开深层嵌套，又让逻辑可配置、易测试；状态码还能存进日志，方便排查哪条分支被触发
- 真特别复杂时，拆成多个存储过程，用
CALL分段调用，比堆 10 个ELSEIF更可靠
IF 块里能执行 INSERT/UPDATE/SELECT，但错误不会自动中断
MySQL 存储过程默认是“继续执行模式”：某条 INSERT 因唯一键冲突失败，不会跳出当前 IF 块，后续语句照常运行——容易掩盖问题，甚至造成数据不一致。
- 必须配合事务：
START TRANSACTION开头，DECLARE EXIT HANDLER FOR SQLEXCEPTION紧跟其后，确保出错时自动ROLLBACK -
IF分支里的SELECT若用于赋值（如SELECT col INTO @var FROM t），记得处理“无匹配行”情况（否则@var会保持旧值或NULL） - 避免在
IF里反复调用函数或子查询——真正影响性能的是条件本身的开销，不是语法选择 - 浮点比较务必用
ABS(a - b) < 0.0001替代a = b，否则精度误差会导致逻辑跳变
最容易被忽略的是：IF 是流程控制语句，而查询中的 IF() 函数只是表达式，两者语法、作用域、NULL 处理方式完全不同——混用就会在调试时反复卡住，而且报错信息往往不指向真实问题点。
