IIF仅适用于极简、确定、无副作用的二选一场景，不是CASE的替代品；它要求单布尔表达式、非NULL输入、轻量无副作用分支、类型兼容，否则易报错或性能异常。

IIF 在 SQL Server 中只适合极简、确定、无副作用的二选一场景，不是 CASE 的平替。 它写起来短，但一旦分支里有子查询、除零、NULL 或类型不一致，就立刻翻车——而且你很难提前发现。

什么时候能放心用 IIF

只有全部满足以下条件时，IIF 才比 CASE 更安全、更清晰：

• 判断表达式是单个布尔式，比如 status = 'A' 或 amount > 1000，不含 AND/OR
• 输入字段确定不为 NULL；若可能为 NULL，你已确认它该归入 false_value 分支（因为 IIF(NULL, 'Y', 'N') 返回 'N'）
• 两个分支都是轻量表达式：不含子查询、不含 1/0 这类风险运算、不含 GETDATE() 这类副作用函数
• 返回值类型兼容，避免隐式转换导致截断，例如 IIF(1=1, 'yes', 123) 返回 varchar，但 IIF(1=1, 123, 'no') 会把 123 转成 '123'

IIF 报错或性能差的典型原因

它最隐蔽的问题是：两个分支都会执行，不是短路计算。这和 CASE 的行为完全不同。

• IIF(@flag = 1, (SELECT COUNT(*) FROM orders), 0) —— 即使 @flag 是 0，子查询仍执行，拖慢查询
• IIF(1=0, 1/0, 999) —— 直接报 Divide by zero error，哪怕条件为假
• IIF(1=1, GETDATE(), NEWID()) —— 两个函数都调用，时间戳和 GUID 都生成，只返回前者
• 嵌套超过 10 层就失败：IIF(a>1,'1', IIF(a>2,'2', ...)) 第 11 层报 Incorrect syntax near 'IIF'

该用 CASE 的明确信号

只要出现下面任一情况，就该立刻换回 CASE WHEN：

• 需要三选一（比如 “高/中/低”），IIF 无法扩展
• 分支里有 IS NULL 判断以外的空值逻辑，比如想把 NULL 单独处理为 'missing'
• 要复用 NULLIF 或 ISNULL 的索引友好特性，IIF(col = b, NULL, col) 效果类似但多一次计算
• 目标平台是 Azure Synapse Analytics 专用 SQL 池——它根本不支持 IIF
• 条件表达式含 OR、IN、复杂日期计算等，可读性已不如 CASE

真正容易被忽略的是：分支是否“轻量”，不取决于你写的代码多短，而取决于 SQL Server 实际执行时会不会触发 IO、锁、计算或副作用。哪怕只是多一个 LEN() 或 ISNUMERIC()，在百万行上也可能放大成严重瓶颈。