iif仅适用于单布尔表达式、无null风险、分支轻量且类型兼容的简单二元判断；否则应使用case，因其支持短路计算、复杂逻辑、多分支及跨平台兼容。
IIF 在 SQL Server 中确实能简化简单二元判断，但它的“简单”有明确定义：仅限单布尔表达式、无 NULL 风险、分支轻量、类型兼容。超出这个范围，它不是简化，而是埋雷。
什么时候可以直接用 IIF？看这四个硬条件
别凭感觉写 IIF，先逐条核对：
- 判断必须是单个布尔表达式，比如
Status = 'A'或Amount > 1000；带AND/OR的复合条件（如Status = 'A' AND Type = 'X'）建议直接上CASE - 所有参与判断的字段必须确定不为
NULL；如果Col可能为NULL，而你期望它走false_value分支，得确认业务逻辑是否真允许——因为IIF(Col > 10, 'Y', 'N')遇到NULL会返回'N'，不是跳过 - 两个分支都必须是轻量表达式：不能含子查询、不能有除零风险（
IIF(1=0, 1/0, 999)会报错）、不能调用副作用函数（GETDATE()、NEWID()等都会被执行两次） - 两个分支返回值类型要兼容，避免隐式转换截断；比如
IIF(1=1, 'yes', 123)返回varchar，但反过来IIF(1=1, 123, 'no')会让123被转成字符串'123'，可能影响后续计算或索引使用
IIF 报错或性能差？大概率是因为分支被强制求值
SQL Server 不做短路计算：true_value 和 false_value 都会执行，不管条件真假。这是最常被忽略的底层行为。
-
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 层？SQL Server 会直接拒绝
IIF 在内部完全重写为 CASE，而 CASE 最大嵌套深度就是 10 层。以下写法在第 11 层就会失败：
IIF(a > 1, '1', IIF(a > 2, '2', IIF(a > 3, '3', ... )))
一旦需要三选一（比如 “高/中/低”），或者分支逻辑稍复杂，就必须切回 CASE。别硬撑。
Azure Synapse 或跨数据库迁移？别依赖 IIF
IIF 是 SQL Server 2012+ 特有语法，Azure Synapse Analytics 专用 SQL 池明确不支持；PostgreSQL、MySQL、Oracle 等主流数据库也不认。如果代码有可移植性要求，或未来可能迁移到云数仓，CASE 是唯一稳妥选择。
真正该问的不是“能不能用 IIF”，而是“这个分支里有没有哪怕一个不确定因素”——只要存在可能的 NULL、慢查询、除零、类型隐式转换，就该立刻换 CASE。简洁不该以隐蔽风险为代价。
