IIF适用于字段非空、逻辑明确的单次布尔判断场景，如状态映射或数值阈值分界；它不支持多分支、空值显式控制或短路计算，内部被转为CASE执行，无性能优势且兼容性弱于CASE。
IIF 在 SQL Server 中确实比 CASE 简洁，但仅限于“真/假”二选一，且不能替代 CASE 的多分支或空值显式控制能力。
什么时候 IIF 能真正简化写法
IIF 适合字段非空、逻辑明确、只需一次布尔判断的场景，比如状态映射、数值阈值分界、简单标记生成。
- 字段本身不为
NULL，或你已确认NULL应统一归入false_value分支（因为IIF(condition, a, b)中 condition 为NULL时，结果就是b） - 不需要处理多个条件组合（如
WHEN status = 'A' AND amount > 1000），IIF 不支持这种写法 - 返回值类型差异不大，避免隐式转换导致意外截断（例如
IIF(1=1, 'yes', 123)返回字符串'yes'，但IIF(1=1, 123, 'no')可能返回'123'） - 不嵌套超过 10 层——IIF 实际会被 SQL Server 内部转成
CASE，而CASE最大嵌套深度是 10
IIF 和 ISNULL / NULLIF 的关键区别
别把 IIF 当成 ISNULL 的快捷写法。它们解决的问题完全不同：
-
ISNULL(col, 'default')只检测col是否为NULL，不是NULL就原样返回；IIF(col IS NULL, 'Y', 'N')是完整布尔表达式，可写任意条件 -
NULLIF(a, b)是“相等即转 NULL”，和条件分支无关；误用IIF(a = b, NULL, a)虽然效果类似，但多一次计算，且无法利用NULLIF的索引友好特性 -
IIF(col > 100, 'high', 'low')无法用ISNULL或NULLIF替代，这是它的不可替代场景
容易被忽略的执行行为：两个分支都会求值
IIF 不是短路计算——无论 condition 结果如何，true_value 和 false_value 都会被 SQL Server 计算一次。这在以下情况会出问题：
- 分支里含子查询：
IIF(@flag = 1, (SELECT COUNT(*) FROM huge_table), 0)即使@flag <> 1，子查询仍会执行 - 分支含除零或类型错误：
IIF(1=0, 1/0, 999)会直接报错，不会跳过1/0 - 分支含函数副作用（如
GETDATE()、NEWID()）：IIF(1=1, GETDATE(), GETDATE())会调用两次，返回两个不同时间戳
和 CASE 的性能与兼容性对比
表面上 IIF 更短，但实际没有性能优势，反而有隐藏成本：
- SQL Server 总是把
IIF重写为等价CASE执行，执行计划完全一致 -
IIF在 Azure Synapse Analytics 专用 SQL 池中不支持，而CASE全平台通用 - 当需要加注释或后续扩展为三选一（比如加个 “待定” 分支），
IIF必须重构成CASE，不如一开始就用CASE稳定 - 团队协作中，有人可能误以为
IIF(col, 'Y', 'N')中的col是“非空即真”，其实它只对0/''/NULL判假——这个隐含规则比CASE WHEN col IS NOT NULL THEN ...更难一眼看懂
真正该警惕的不是语法长短，而是布尔表达式的语义是否清晰、分支计算是否安全、以及未来两周会不会有人要在这个逻辑上加第三种情况。
