IIF只是CASE的语法糖，仅适用于单布尔条件、非空字段、无副作用的轻量分支；它不短路执行，两分支均被求值，嵌套限10层，三选一或复杂逻辑必须用CASE。
IIF 在 SQL Server 2019 中确实能简化“二选一”的布尔判断，但它的适用范围很窄——只适合字段非空、条件单一、分支无副作用的场景。它不是 CASE 的替代品，而是语法糖，内部完全转成 CASE 执行。
什么时候用 IIF 真正省事？
仅当满足全部以下条件时，IIF 才比 CASE 更直观：
- 判断逻辑是单个布尔表达式，比如
status = 'A'或amount > 1000，不带AND/OR组合 - 输入字段确定不为
NULL，或你明确接受NULL条件结果为false_value（因为IIF(NULL, 'Y', 'N')返回'N'） - 两个分支都是轻量级表达式：不含子查询、不含除零风险、不含
GETDATE()等有副作用的函数 - 返回值类型兼容，避免隐式转换截断，例如
IIF(1=1, 'yes', 123)返回varchar，但IIF(1=1, 123, 'no')可能返回varchar并把123转成'123'
IIF 的坑：两个分支都会执行
这是最容易被忽略的行为：IIF 不是短路计算。无论条件真假，true_value 和 false_value 都会被 SQL Server 求值一次。
-
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())—— 两个函数都调用，但只返回GETDATE()结果；时间戳和 GUID 都已生成，只是丢弃了后者
嵌套超过 10 层就失败
IIF 最多支持 10 层嵌套，因为 SQL Server 内部把它重写为 CASE，而 CASE 的最大嵌套深度就是 10。
- 像
IIF(a>1, '1', IIF(a>2, '2', IIF(a>3, '3', ...)))这种写法，到第 11 层就会报错Incorrect syntax near 'IIF'（实际是嵌套超限） - 一旦业务逻辑需要三选一（比如 “高/中/低”），就必须改用
CASE，IIF无法扩展 - Azure Synapse Analytics 专用 SQL 池不支持
IIF，而CASE全平台通用
真正关键的不是“能不能写”，而是“值不值得写”。如果分支里有任意一点不确定性（比如可能 NULL、可能慢查询、可能出错），就该直接用 CASE——它语义清晰、行为可预测、团队协作时没人会误解。简洁不该以隐蔽风险为代价。
