SQL Server中IF...ELSE基本写法为：IF条件后接单条语句可省略BEGIN...END，执行多条语句则必须用BEGIN...END包裹；ELSE须紧接END后，不可有空行或注释；嵌套不宜超3层，否则影响可读性。
SQL Server 中 IF...ELSE 的基本写法和作用域限制
IF...ELSE 在 SQL Server 存储过程中是过程控制的核心，但它不支持像编程语言那样的嵌套块作用域——每个 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 分支，而是当业务规则变更时，要在三套语法里同步维护同一套条件逻辑。建议把核心判断抽成视图或标量函数，让存储过程只做“调度”，降低耦合。
