SQL Server中IF ELSE基本写法：单语句可省略BEGIN END，多语句必须用BEGIN END包裹；ELSE须紧接END后，不可有空行或注释；嵌套不宜超3层，避免逻辑错位和可读性下降。
SQL Server 中 IF ELSE 的基本写法和常见错误
SQL Server 存储过程中直接支持 IF/ELSE，但必须用 BEGIN/END 明确包裹多语句块。漏掉 BEGIN...END 是最常导致逻辑错乱的坑——比如只有一行 PRINT 被条件控制，后面几行 UPDATE 却无条件执行。
正确写法示例：
IF @status = 'active'
BEGIN
UPDATE users SET last_login = GETDATE() WHERE id = @user_id;
INSERT INTO log (msg) VALUES ('login recorded');
END
ELSE
BEGIN
RAISERROR('User not active', 16, 1);
END
-
IF后面不能跟分号，BEGIN必须顶格或紧跟换行，否则可能被解析为语句分隔符问题 - 嵌套
IF时，每个ELSE默认绑定到最近未配对的IF，不靠缩进判断逻辑归属 - 布尔表达式里慎用
= NULL，必须用IS NULL，否则整个分支永远不触发
MySQL 存储过程里 IF ELSE 的语法差异与陷阱
MySQL 不支持裸 IF @x > 0 THEN 这种写法，所有条件判断必须用 IF ... THEN ... END IF; 闭合，且 THEN 后不能加分号。少一个 END IF 就会报 ERROR 1064，但错误位置提示往往指向后续语句，容易误判。
正确结构：
IF v_count > 0 THEN
SET @msg = 'found';
UPDATE stats SET hits = hits + 1;
ELSEIF v_count = 0 THEN
SET @msg = 'empty';
ELSE
SET @msg = 'error';
END IF;
-
ELSEIF是一个词（不是ELSE IF），中间不能有空格，否则报语法错误 - 变量必须先
DECLARE，且作用域仅限当前BEGIN...END块；在IF内部DECLARE会报错 - MySQL 8.0+ 支持
CASE WHEN表达式用于赋值，但不能替代完整分支逻辑（比如不能在CASE里执行INSERT）
用 CASE WHEN 替代 IF ELSE 的适用场景与性能考量
当分支逻辑只涉及单个值计算或字段赋值时，CASE WHEN 比 IF 更轻量、更易内联，且在 SELECT 或 UPDATE 中天然支持。但它不能执行语句，也不能控制事务流程。
例如在 UPDATE 中动态设值：
UPDATE orders
SET status = CASE
WHEN paid_date IS NOT NULL THEN 'shipped'
WHEN DATEDIFF(day, created_at, GETDATE()) > 30 THEN 'expired'
ELSE 'pending'
END;
-
CASE是表达式，返回一个值；IF是语句，控制执行流——二者不在同一抽象层，不可混用 - 在存储过程中混合使用时，别在
IF分支里又写一大段CASE，可读性骤降；优先把值计算抽成变量，再用IF控制后续动作 - SQL Server 中
CASE在 WHERE 或 ON 条件里可能导致索引失效，尤其带函数调用时；而IF判断本身不参与查询计划生成
跨数据库兼容写法：为什么尽量避免 IF ELSE
PostgreSQL 不支持存储过程级 IF（直到 11+ 才在 DO 块中支持，且语法不同），Oracle 用 IF ... THEN ... END IF; 但要求 DECLARE 块前置。真要写“一次编写、多库运行”的逻辑，几乎只能靠应用层判断，或用 CASE + 动态 SQL 绕过。
- 如果业务逻辑本质是数据路由（比如按地区分表插入），优先用应用代码做分支，存储过程只做原子操作
- 必须用分支时，把条件判断提到最外层，用不同存储过程名区分路径（如
proc_insert_us/proc_insert_eu），比在同一个过程里堆IF更易测试和维护 - 所有分支共用的参数校验、日志记录、错误包装，应抽到独立过程或用
TRY...CATCH（SQL Server）/DECLARE EXIT HANDLER（MySQL）统一处理
真正难的不是写对 IF ELSE，而是判断哪部分该交给数据库，哪部分该收回来——边界模糊时，先跑慢查询日志，再看执行计划里的分支是否成了性能瓶颈。
