在 SQL Server 2019 中，IIF 函数确实能让代码更简洁——只需一行就能完成简单判断，看起来干净利落。不过，从实际使用角度看，它并非万能的替代方案，更像是 CASE 的一个“语法糖”。用得恰当可以省时省力，用错了则会埋下隐患。
先明确核心判断：IIF 只适用于那些“布尔条件判断 + 两个非空且无副作用的轻量分支”的场景。至于三选一、复杂逻辑或可能带有 NULL 的字段，老老实实使用 CASE 才是最稳妥的做法。
核心要点：什么时候该用？
想在代码中熟练使用 IIF，必须同时满足以下条件——缺少任意一个都不建议强行使用：
- 判断逻辑必须是单个布尔表达式，例如
status = 'A'或amount > 1000，不要包含AND/OR组合条件 - 用于判断的字段不能为
NULL——如果字段值为NULL，IIF(NULL, 'Y', 'N')直接返回'N'，虽然结果可接受，但必须心中有数 - 两个分支都必须是轻量表达式：禁止子查询、避免除零风险、杜绝
GETDATE()这类有副作用的函数 - 返回值类型应兼容，防止隐式转换导致结果被截断。例如
IIF(1=1, 'yes', 123)返回varchar，但IIF(1=1, 123, 'no')会将123静默转换为'123'
只要有一条不满足，就应停下来思考：是不是 CASE 才是更好的选择。
最容易踩的坑：两个分支都会执行
这是 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 层会直接失败。原因是 SQL Server 内部将 IIF 重写为 CASE，而 CASE 的最大嵌套深度就是 10。像 IIF(a>1, '1', IIF(a>2, '2', IIF(a>3, '3', ...))) 这种写法，一旦超过 10 层就会报错 Incorrect syntax near 'IIF'。
业务逻辑如果需要三选一（例如“高/中/低”），IIF 就完全无法胜任，必须切换回 CASE。
另外，Azure Synapse Analytics 的专用 SQL 池不支持 IIF——这对跨平台迁移而言是一个不小的隐患。而 CASE 是所有平台都认可的“通用语言”。
说到底，核心问题不是“能不能写”，而是“值不值得写”。如果分支中包含任何不确定性——可能是 NULL、慢查询、除零风险——就应该直接使用 CASE。它语义清晰、行为可预测，团队中任何人都不会误解。请记住：简洁，不应以隐蔽风险来换取。
