sql存储过程条件判断的关键在于适配不同数据库语法：sql server需begin end包裹多行且else紧接end；mysql用if...then...end if且关键字连写；均须注意null处理、浮点比较及嵌套深度。
直接说结论：SQL存储过程中写条件判断，不是“会不会”的问题，而是“在哪种数据库里怎么写才不翻车”的问题。语法差异大、NULL处理反直觉、嵌套层级一深就漏 END IF 或 BEGIN...END，这些才是真实阻碍落地的点。
SQL Server 里 IF 必须用 BEGIN END 包多行语句
很多人写完 IF @status = 'A' 后直接跟两行语句，结果只有第一行受控，第二行无条件执行——因为 SQL Server 默认只把紧接在 IF 后面的**单条语句**纳入分支作用域。
- 正确写法必须显式包裹：
IF @status = 'A' BEGIN UPDATE ...; INSERT ...; END -
ELSE必须紧跟在END后面，中间不能有空行或注释（某些版本会报错） - 判断 NULL 时别写
@val = NULL，永远返回 UNKNOWN，得用@val IS NULL - 嵌套超过 3 层就该警惕：缩进难维护、逻辑易错位，建议提前用变量归一化状态再单层判断
MySQL 存储过程的 IF 是语句级结构，不是函数
最常踩的坑是把查询里的 IF() 函数（比如 SELECT IF(status=1,'Y','N')）和过程控制的 IF ... THEN ... END IF; 混为一谈。前者只能返回值，后者才能执行 INSERT、UPDATE 等操作。
- 关键字必须连写：
ELSEIF，不是ELSE IF（空格即报错 ERROR 1064） - 每个分支末尾都要加分号，
END IF;也不例外 - 条件中含 NULL 时，整个布尔表达式可能变成 UNKNOWN，导致误入
ELSE；稳妥写法是IF @type IS NULL OR @type = 'user' - 浮点比较别用
=，改用ABS(a - b)
PostgreSQL 要用 plpgsql，IF 不在标准 SQL 函数里
用 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；优先用IS NOT DISTINCT FROM（PostgreSQL）或ISNULL(@x, '') = ISNULL(@y, '')（SQL Server） - 在
IF分支里执行UPDATE前，如果前面已有BEGIN TRANSACTION，记得每个分支都配对COMMIT或ROLLBACK，否则可能卡住事务 - MySQL 用
SIGNAL抛异常时，DECLARE EXIT HANDLER必须在SIGNAL**之前**声明，且仅对当前BEGIN...END块生效 - PostgreSQL 的
EXCEPTION块只捕获指定错误码（如unique_violation对应'23505'），写WHEN OTHERS会吞掉磁盘满这类致命错误
真正容易被忽略的是：条件判断本身不难，难的是它和 NULL、事务、错误传播、并发安全这四者的耦合。写完一个 IF，先问自己——这个分支里有没有可能读到 NULL？有没有可能被并发修改干扰？失败了要不要回滚？错误信息能不能被上层捕获？没想清楚就上线，90% 的问题都出在这儿。
