是，IF/CASE分支顺序直接影响性能。SQL Server、PostgreSQL、MySQL、Oracle均严格顺序求值，高频路径应前置；需避免NULL陷阱、隐式转换及分支内耗时函数调用，优先将轻量判断放前面并缓存复杂计算结果。
SQL Server 中 IF 条件分支的执行顺序真的影响性能？
影响非常直接。SQL Server 不会提前“预判”哪个分支更可能命中，而是从上到下逐条求值 WHEN 或 IF 表达式，一旦为真就跳过后续分支。这意味着高频路径越靠前，平均判断开销越小——尤其当条件本身涉及函数调用、子查询或列计算时。
常见错误现象：IF @status = 'draft' ... ELSE IF @status = 'published' ... ELSE IF @status = 'archived'，但线上 95% 请求都是 'published'，却排在第二位。
- 优先把统计上最常触发的分支写在最前面（不是按字母序，也不是按业务流程图顺序）
- 避免在条件中写
ISNULL(@input, '') != ''这类隐式转换表达式；改用@input IS NOT NULL AND @input != ''，既明确又利于短路 - 如果分支逻辑差异极大（比如一个查表、一个只赋值），高频路径还应尽量减少其内部 I/O 或计算量，不能只靠“放前面”来补救
PostgreSQL 的 CASE WHEN 分支要不要重排？
要，而且效果比 SQL Server 更明显。PostgreSQL 的 CASE WHEN 是严格顺序求值，且每个 WHEN 子句的表达式都会完整执行（无编译期优化跳过）。如果你在 WHEN 里写了 (SELECT COUNT(*) FROM huge_log WHERE event_time > NOW() - INTERVAL '1h')，而它排在第一位但命中率仅 0.1%，那每次调用都白跑一次全表扫描。
使用场景：报表存储过程、ETL 调度逻辑、状态机驱动的数据清洗。
- 把基于简单变量比较的分支（如
WHEN status = 'active'）放在最前，复杂子查询或函数调用的分支往后挪 - 不要依赖
ELSE当兜底——它永远最后执行，若高频路径被误归入ELSE，等于主动放弃优化机会 - 注意
CASE在SELECT子句和在IF逻辑块中的行为一致，都遵循顺序求值
MySQL 存储过程中 IF-ELSEIF 的坑：NULL 判断必须显式写
MySQL 对 NULL 的三值逻辑处理很“诚实”，但容易踩坑。比如 IF @type = 'user' THEN ... ELSEIF @type = 'admin' THEN ...，当 @type 是 NULL 时，两个条件都返回 UNKNOWN，结果直接掉进 ELSE——哪怕你本意是“NULL 算作未指定，默认走 user 分支”。
性能影响：看似只是逻辑错，实则可能让高频的默认路径被绕过，触发低效的备用逻辑（比如查配置表而非用硬编码值）。
- 高频默认分支必须显式包含
IS NULL或IS NOT NULL判断，例如IF @type IS NULL OR @type = 'user' - 避免用
=直接比较可能为NULL的参数；优先用安全等于操作符，但注意它不支持索引下推，仅适合变量间比较 - 如果分支依据来自查询结果（如
SELECT status INTO @s FROM orders...），记得检查该字段是否允许NULL，并在分支开头加防御性判断
Oracle PL/SQL 中 ELSIF 分支的短路特性别误信
PL/SQL 确实支持短路，但仅限于布尔表达式本身。一旦你在 ELSIF 条件里调用了函数（比如 ELSIF validate_input(@data) THEN），这个函数**一定会被执行**，哪怕前面的 IF 已经为真。这不是 bug，是语言设计：函数调用属于表达式求值的一部分，不会被跳过。
容易被忽略的地方：很多人以为把 validate_input() 放后面就“省了调用”，其实只要它出现在某个 ELSIF 行里，就逃不掉。
- 高频路径分支的条件，只保留轻量判断（变量比较、常量匹配），把耗时函数调用提到分支外部，用中间变量缓存结果
- 如果必须在条件中调用函数，确保它已做足够缓存（比如包级变量 + 标志位），避免重复解析或远程调用
- 用
DBMS_PROFILER实际抓一次典型调用栈，确认哪些函数真被跳过了、哪些没躲开——直觉常不准
真正关键的不是“怎么排”，而是清楚每条分支里实际执行了什么。一个看似简单的 ELSIF 行，背后可能是三次远程服务调用加两次 XML 解析。
