case when仅返回值，不能控制执行流；多分支逻辑必须用嵌套if，每个分支需begin...end包裹，避免漏写else导致静默失败。

SQL Server 里用 CASE WHEN 做多分支判断，但别指望它能替代程序语言的 IF...ELSE IF...

SQL Server 的 CASE WHEN 是表达式，不是控制流语句——它只能返回一个值，不能执行语句块、跳过某段逻辑、或提前退出。真要实现“满足条件A就执行X，否则检查B再执行Y，都不满足才执行Z”，必须用嵌套 IF。

常见错误是硬套 CASE 写一堆 SELECT 或 UPDATE，结果报错：A CASE statement cannot be used to control the flow of execution。记住：只有 IF 能控制执行流。

• IF @status = 'pending' BEGIN UPDATE orders SET ... END
• 多个条件用 ELSE IF 链接，注意每个分支都得用 BEGIN...END 包裹（哪怕只有一行）
• 避免漏写 ELSE 导致逻辑静默失败；宁可加个 ELSE THROW 50000, 'unhandled status', 1 显式报错

PostgreSQL 存储过程（PL/pgSQL）中用 IF ELSIF ELSE 是标准解法

PostgreSQL 从 11+ 支持过程语言 PL/pgSQL，语法和传统编程语言一致，ELSIF 就是 ELSE IF 的缩写，支持嵌套、变量赋值、异常捕获。

容易踩的坑是把 IF 写在函数体外，或者混淆函数（FUNCTION）和过程（PROCEDURE）：只有 PROCEDURE 才能执行 DML 不返回值；FUNCTION 必须有 RETURN，且默认 STABLE 或 IMMUTABLE 会缓存结果，导致分支逻辑失效。

• 声明变量用 DECLARE 块，IF 必须在 BEGIN ... END 内
• ELSIF 后面不加 THEN 是语法错误，必须写成 ELSIF condition THEN
• 分支内调用其他过程时，记得加 CALL（v14+）或用 PERFORM + 函数调用

MySQL 存储过程中 IF ... ELSEIF ... ELSE ... END IF 语法最直白，但注意分号和 delimiter

MySQL 的 IF 语句本身没问题，真正卡住人的是 DELIMITER 设置。因为存储过程体里有分号，不改分隔符会导致 MySQL 把第一个 ; 当作整个 CREATE PROCEDURE 语句结束，后续内容直接报错。

另一个隐蔽问题是变量作用域：在 IF 分支里用 DECLARE 定义的变量，只在当前 BEGIN...END 块内有效。如果想跨分支共享状态，得用 SET @var := value 这种会话级用户变量（但要注意并发安全）。

• 必须先 DELIMITER $$，结尾写 $$，再恢复 DELIMITER ;
• ELSEIF 是一个词（无空格），不是 ELSE IF，写错会报 Unknown routine
• 分支里执行 INSERT/UPDATE 后，记得检查 ROW_COUNT()，避免条件成立但实际没更新到数据

Oracle PL/SQL 的 IF ELSIF ELSE 最严谨，但 EXCEPTION 处理常被忽略

Oracle 的语法和其他数据库类似，但它的强类型和异常传播机制让多分支逻辑更可靠。真正容易出问题的是：分支里抛了异常，却没在对应层级 EXCEPTION 块捕获，导致整个事务回滚，而上层调用方只看到 ORA-06512 这种堆栈信息，根本看不出是哪个分支出的错。

另外，ELSIF 条件表达式里如果用了函数（比如 TO_DATE），而输入可能为空或非法格式，不加 EXCEPTION WHEN VALUE_ERROR THEN 就会直接中断流程。

• 每个 IF 分支末尾必须有 END IF;，少个分号或写成 ENDIF 都报错
• 用 DBMS_OUTPUT.PUT_LINE 打印调试信息时，确保客户端已启用 SET SERVEROUTPUT ON
• 涉及日期/数字转换的分支，优先用 TO_CHAR/TO_NUMBER 的带格式版本，避免隐式转换失败

复杂分支逻辑里，最常被绕开的是事务边界和错误传播路径。写完每个 IF 分支，得问一句：这里出错，该不该回滚前面的操作？上层能不能拿到有意义的错误码？而不是只盯着语法对不对。