MySQL 5.7 存储过程必须用连写的IF-ELSEIF-ELSE-END IF结构，ELSEIF不可有空格，THEN不可省略，END IF后必须加分号；混用IF()函数无法执行多语句，且NULL比较易致逻辑错误。
IF-ELSEIF-ELSE 必须连写，不能有空格或换行断开
MySQL 5.7 存储过程里写条件分支，IF、ELSEIF、ELSE、END IF 是硬性语法块，不是风格选择。复制代码时若把 ELSEIF 写成 ELSE IF（中间带空格），直接触发 ERROR 1064；THEN 不可省略；END IF 后必须加分号，漏一个整个存储过程就创建失败。
常见错误现象：
-
CREATE PROCEDURE执行报错：「You have an error in your SQL syntax」且指向ELSE行 - 嵌套内层
IF缺少END IF;，导致外层END IF被误解析为内层闭合
正确写法示例：
IF @score >= 90 THEN SET @grade = 'A'; ELSEIF @score >= 80 THEN SET @grade = 'B'; ELSEIF @score >= 70 THEN SET @grade = 'C'; ELSE SET @grade = 'F'; END IF;
避免用 IF() 函数嵌套替代流程控制
IF() 是表达式函数，用于 SELECT 或赋值语句中返回值；而 IF 语句是流程控制结构，只能在存储过程/函数体内使用。两者混用极易踩坑：
- 在存储过程中写
SET @x = IF(@a>1, IF(@b=2, 'yes', 'no'), 'fail');—— 这属于表达式嵌套，最多撑到 15–20 层就可能触发解析失败或内存不足 - 想实现多分支逻辑却用
IF()套娃，可读性差、调试困难，且无法配合INSERT/UPDATE等语句 -
IF()对NULL比较不敏感（NULL = 1返回NULL，不是FALSE），容易让分支意外落入value_if_false
真正需要分支执行动作时，必须用 IF 语句块，而不是堆 IF() 函数。
游标 + 嵌套查询是性能杀手，优先改写为 JOIN 或派生表
存储过程中一旦出现游标遍历，再在循环体内执行 SELECT 或 UPDATE，就会形成 N×M 查询放大。比如游标扫 1000 行，每行查一次关联表，实际发出 1000 条独立查询——这比单条带 JOIN 的语句慢一个数量级。
- 不要写：
FETCH cur INTO @id; SELECT name FROM users WHERE id = @id; - 应改写为：
SELECT u.name FROM orders o JOIN users u ON o.user_id = u.id WHERE ... - 若必须模拟“每行取最新一条子记录”（如每个订单的最新物流状态），MySQL 5.7 不支持
LATERAL，得用派生表 +GROUP BY+MAX()配合回连，但要注意：派生表默认物化（select_type=DERIVED），需确认是否走索引
嵌套过深时，拆分为多个小存储过程更可控
单个存储过程里 IF 嵌套超 4 层、或混合游标+事务+错误处理器，出错时定位困难，且 MySQL 5.7 解析器对复杂结构容忍度低。与其硬扛，不如按职责拆分：
- 把数据校验逻辑单独抽成
check_order_status() - 把状态更新封装为
update_order_state() - 主过程只做调度：
CALL check_order_status(@order_id, @valid); IF @valid THEN CALL update_order_state(@order_id); END IF; - 拆分后每个过程职责清晰，便于单元测试，也规避了深层嵌套带来的语法和逻辑风险
真正难的不是写满屏幕的 IF 块，而是让每一层都明确知道它该管什么、不该碰什么——边界不清，才是嵌套失控的根源。
