不同数据库中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，而是想清楚“这个条件到底代表什么业务含义”——是参数缺失？是数据不存在？还是业务规则不满足？一旦定义模糊，后面所有分支都会跟着偏移。

《夸克》非常好用的免费AI浏览器

下载APP查看