不同数据库中IF分支语法差异大且易出错：SQL Server需BEGIN END包裹多行、MySQL要求ELSEIF连写、PostgreSQL必须用plpgsql语言并注意ELSIF拼写，三值逻辑和事务边界是跨库通用陷阱。
不是语法会不会的问题，而是不同数据库里写法稍有偏差就会直接报错或逻辑失控。 比如 SQL Server 里漏掉 BEGIN END，只有第一行受 IF 控制；MySQL 把 ELSE IF 写成带空格就报 ERROR 1064；PostgreSQL 不切到 plpgsql 语言，IF 根本不识别——这些都不是“学不会”，是“一写就翻车”。
SQL Server 中多行语句必须用 BEGIN END 包裹
很多人写完 IF @status = 'A' 后直接跟两行语句，结果第二行永远无条件执行。SQL Server 默认只把紧接在 IF 后面的**单条语句**纳入作用域。
- 正确写法：必须显式加
BEGIN和END，且ELSE必须紧贴END后面，中间不能有空行或注释（某些版本会报错） -
NULL判断永远别写@val = NULL，得用@val IS NULL - 嵌套超过 3 层就该警惕：缩进难维护、
END容易漏写，建议提前用变量归一化状态再单层判断 - 事务控制别靠手工
TRY...CATCH，开头加一句SET XACT_ABORT ON更可靠
MySQL 存储过程的 IF 是语句级结构，不是函数
最常踩的坑是把查询里的 IF() 函数（比如 SELECT IF(status=1,'Y','N')）和过程控制的 IF ... THEN ... END IF; 混为一谈。前者只能返回值，后者才能执行 INSERT、UPDATE 等操作。
- 关键字必须连写：
ELSEIF，不是ELSE IF（空格即报错） - 每个分支末尾都要加分号，
END IF;也不例外 - 条件中含
NULL时，整个布尔表达式可能变成UNKNOWN，稳妥写法是IF @type IS NULL OR @type = 'user' - 浮点比较别用
=，改用ABS(a - b) < 0.001
PostgreSQL 要用 plpgsql 才支持 IF 分支
用 CREATE FUNCTION ... LANGUAGE SQL 写出来的函数，压根不支持 IF。必须切到 plpgsql，且声明部分（DECLARE）得放在 BEGIN 之前，否则直接报错 syntax error at or near "IF"。
-
ELSIF是一个词，不是ELSE IF；后者会被解析成ELSE后跟一个新IF，需要两个END IF - 常用异常条件如
NOT FOUND可直接用于判断：IF NOT FOUND THEN，比查ROW_COUNT更可靠 - 想在
SELECT中做分支计算？用CASE WHEN ... THEN ... END表达式；想根据结果执行 DML？必须进plpgsql的IF块 -
PERFORM替代SELECT用于只执行不返回结果的查询，避免意外抛出结果集中断调用
跨数据库通用陷阱：NULL 和事务边界
所有数据库都共享同一个底层问题：三值逻辑让 NULL 参与的条件判断不可靠；而分支里混用 DML 和事务控制，又极易造成部分成功、回滚不一致。
- 别依赖
IF @x = @y判断相等，尤其当其中一个是NULL时，永远返回UNKNOWN - 存在性判断优先用
IF EXISTS (SELECT 1 FROM t WHERE ...)，而不是IF (SELECT COUNT(1) FROM t WHERE ...) > 0—— 前者找到首行即终止，后者强制全量计数 - 字符串参数是否为空，要区分
NULL和''：用LEN(ISNULL(@name, '')) > 0，而不是@name != '' - 动态 SQL 拼接时，数字参数必须用
CONVERT(VARCHAR, @id)转换，字符串必须用REPLACE(@name, '''', '''''')转义单引号
真正难的不是写对一个 IF，而是想清楚“这个条件到底代表什么业务含义”——是参数缺失？是数据不存在？还是业务规则不满足？一旦定义模糊，后面所有分支都会跟着偏移。
