在编写存储过程时，条件分支逻辑是绕不开的核心技能。不同数据库的 IF...ELSE 语法差异很大，稍不注意就容易踩坑。先把基本写法讲清楚，再说一些常见的疑难杂症。
SQL Server 中 IF...ELSE 的基本写法和作用域限制
SQL Server 存储过程中的 IF...ELSE 是过程控制的核心，但它不像编程语言那样支持嵌套块作用域。每个 IF 或 ELSE 后面如果只跟一条语句，可以省略 BEGIN...END；但一旦要执行多条语句，BEGIN...END 就必不可少，漏了会导致语法错误或逻辑错位。
- 错误写法：
IF @status = 1 SELECT 'active'; UPDATE users SET last_login = GETDATE()—— 第二条语句永远无条件执行 - 正确写法：
IF @status = 1 BEGIN SELECT 'active'; UPDATE users SET last_login = GETDATE() END - ELSE 必须紧跟在 END 后，中间不能有空行或注释（某些版本会直接报错）
- 嵌套层级过深时，建议用临时表或变量暂存中间状态，避免 IF 套 IF 超过 3 层，可读性会急剧下降
MySQL 存储过程中 IF 语句的语法差异与常见陷阱
MySQL 的 IF 是语句级结构，必须以 END IF 显式结束，且不允许在普通 SQL 语句中直接使用（比如不能在 SELECT 里写 IF @x > 0 THEN ...），只能出现在存储过程、函数或触发器体内。
- 别把
IF()函数（三元表达式）和过程式 IF 混用：SELECT IF(status=1, 'Y', 'N') FROM t是函数，不能执行 DML；而存储过程里的IF status = 1 THEN INSERT ... END IF才能控制流程 - MySQL 不支持
ELSEIF的缩写ELIF，必须写全ELSEIF - 条件表达式里慎用
IS NULL和= NULL：后者永远为 FALSE，要用IS NULL判断 - 若分支中需动态拼接 SQL 并执行，必须用
PREPARE/EXECUTE，且变量作用域仅限当前BEGIN...END块
PostgreSQL 中没有 IF...ELSE，得用 CASE 或 plpgsql 的 IF
PostgreSQL 的标准 SQL 函数（如 CREATE FUNCTION ... RETURNS TABLE AS $$ ... $$ LANGUAGE SQL）不支持过程式控制流。真要分支逻辑，必须切换到 plpgsql 语言，并用 IF / ELSIF / ELSE / END IF 结构。
- 声明部分必须放在 BEGIN 之前：
DECLARE x INT := 0;，否则报错ERROR: 42601: syntax error at or near "IF" - CASE 表达式只能返回值，不能执行语句；想在 SELECT 中做分支计算可用
CASE WHEN ... THEN ... ELSE ... END，但不能在里面写 INSERT - plpgsql 的 IF 支持布尔表达式，也支持
NOT FOUND这类异常条件，比如IF NOT FOUND THEN RAISE NOTICE 'no row'; END IF; - 注意
PERFORM替代SELECT用于只执行不返回结果的查询，避免意外返回结果集导致调用端报错
跨数据库移植时 IF 分支逻辑最容易出问题的三个点
把 SQL Server 的存储过程迁到 MySQL 或 PostgreSQL 时，IF 相关代码几乎必然要重写，不是语法微调，而是模型差异。
- 空值比较行为不一致：SQL Server 中
SET ANSI_NULLS OFF下@x = NULL可能为 TRUE；MySQL 和 PostgreSQL 默认严格遵循 SQL 标准，= NULL永远 FALSE - 布尔类型支持不同：PostgreSQL 有原生
BOOLEAN，MySQL 用TINYINT(1)模拟，SQL Server 用BIT，在 IF 条件里写IF @flag = 1在 PG 里可能得改成IF flag IS TRUE - 错误中断机制不同：SQL Server 用
THROW或RAISERROR；MySQL 用SIGNAL；PostgreSQL 用RAISE EXCEPTION—— 分支中抛错后是否继续执行后续语句，各引擎策略也不一样
真正麻烦的不是写对某一种数据库的 IF 分支，而是当业务规则变更时，要在三套语法里同步维护同一套条件逻辑。建议把核心判断抽成视图或标量函数，让存储过程只做“调度”，降低耦合。
