IIF仅支持单布尔表达式，不适用于复合条件（如Status = 'A' AND Type = 'X'），因其将整个AND表达式视为一个整体，遇NULL返回false且无短路、无分层判断能力，易偏离业务预期；必须用CASE替代。
IIF 不适合“两条件分支判断”，它只处理单布尔表达式；所谓“两条件”（如 Status = 'A' AND Type = 'X'）必须拆解或改用 CASE。
为什么 IIF 不能真正支持“两条件分支”
IIF 的第一个参数 boolean_expression 在语义上只能是一个**整体求值为 true/false 的单一表达式**，不是“两个条件”的并列判断。SQL Server 不识别所谓“两条件分支”的结构——它只认真假值。把 Status = 'A' AND Type = 'X' 塞进 IIF 第一个参数，看似写了两个条件，实则仍是单个逻辑表达式，且存在隐患：
- 一旦
Status或Type任一列为NULL，整个AND表达式结果为UNKNOWN，IIF 就按 false 处理，返回false_value—— 这未必符合业务预期 - 无法像 CASE 那样分层判断：比如“先看 Status，再看 Type”，IIF 没有短路、没有分支嵌套能力
- 若后续想加第三种情况（如 Status = 'B' → 'Pending'），IIF 只能嵌套，最多 10 层，可读性和维护性迅速崩坏
IIF(1=1, 'Y', 'N') 这类简单场景才安全
只有满足全部四个硬约束时，IIF 才是简化而非挖坑：
-
boolean_expression是原子级的，不含AND/OR，例如Amount > 1000或Status IN ('A', 'C') - 所有参与字段确定不为
NULL；若不确定，应先用ISNULL()或COALESCE()显式处理，而不是依赖 IIF 对 UNKNOWN 的 fallback 行为 -
true_value和false_value都是常量、标量变量或无副作用的轻量表达式（严禁子查询、GETDATE()、NEWID()、除零风险等） - 两边返回类型兼容，避免隐式转换导致截断或索引失效，例如
IIF(IsActive = 1, 1, 0)比IIF(IsActive = 1, 'true', 'false')更利于后续数值计算
IIF 报错或性能差？大概率是分支被强制求值
这是最常被忽略的底层机制：SQL Server 对 IIF 的两个分支**不做短路计算**，无论条件真假，true_value 和 false_value 都会完整执行一次。
-
IIF(@mode = 'COUNT', (SELECT COUNT(*) FROM huge_table), 0)→ 即使@mode是'SUM'，子查询照跑 -
IIF(1=0, 1/0, 999)→ 直接报Divide by zero error encountered. -
IIF(@flag = 1, GETDATE(), SYSDATETIME())→ 两个时间函数都调用，仅返回前者结果，但已消耗资源
这种行为源自 IIF 实际被 SQL Server 内部重写为等价的 CASE 表达式，而标准 CASE 同样不保证短路（尽管优化器有时能剪枝，但不可依赖）。
该用 CASE 的时候别硬套 IIF
当出现以下任一情况，请直接写 CASE：
- 需要判断多个离散值：
CASE Status WHEN 'A' THEN 'Active' WHEN 'I' THEN 'Inactive' ELSE 'Unknown' END - 条件含范围或复合逻辑：
CASE WHEN Amount > 1000 AND Currency = 'USD' THEN 'High' ... - 某一分支需查表或调用函数：
CASE WHEN EXISTS(SELECT 1 FROM logs WHERE order_id = o.id) THEN 'Traced' ELSE 'New' END - 需要 NULL 感知控制（如只在非 NULL 时计算）：
CASE WHEN Col IS NOT NULL THEN Col * 1.1 ELSE Col END，比IIF(Col IS NOT NULL, Col * 1.1, Col)更清晰且规避了 UNKNOWN 陷阱
IIF 的存在意义，只是让 CASE WHEN condition THEN a ELSE b END 这种最简二元模式少敲几个字。一旦逻辑稍复杂，它就从“简化”变成“障眼法”。
