IIF不能简化多层嵌套判断，仅支持严格二元分支；它本质是CASE WHEN的单层三元语法糖，强行嵌套会降低可读性、触发类型隐式转换，并受10层嵌套限制。
IIF 不能简化多层嵌套的条件判断——它本身不支持多层逻辑，强行嵌套只是把问题藏得更深，反而更难维护。
IIF 只接受三个参数，且必须是严格二元分支
IIF 的签名固定为 IIF(condition, then_value, else_value)，没有 ELSEIF，也没有条件列表。
它不是“简化版 CASE”，而是“单次三元运算符”，SQL Server 内部直接把它重写成等价的 CASE WHEN ... THEN ... ELSE ... END。
- 布尔表达式必须能明确求值为
TRUE或FALSE（UNKNOWN会被当作FALSE处理） - 三个参数缺一不可：少一个就报错
Incorrect syntax near ','或Incorrect syntax near ')' -
then_value和else_value类型不一致时，SQL Server 按数据类型优先级隐式转换——比如IIF(x > 0, 1, 'N/A')整体变成varchar，后续参与数值计算会失败
常见误用：
-
IIF(status = 'A', 'Active', IIF(status = 'B', 'Blocked', IIF(status = 'C', 'Cancelled', 'Unknown')))
这已嵌套 3 层，可读性差，且一旦status是NULL，整个链式结果是Unknown而非你预期的空安全分支。
嵌套 IIF 超过 10 层会直接报错
SQL Server 对 CASE 表达式有硬性限制：最大嵌套深度为 10 层。而 IIF 在解析期就被完全展开为 CASE，所以：
- 嵌套 11 层
IIF→ 报错Maximum nesting level exceeded (limit 10) - 即使每层都很简单，只要语法上形成嵌套结构，就计入深度
- 这个限制在视图、函数、CTE、
UPDATE子句中全部生效，不是仅限于SELECT
实际场景中，真正需要 10+ 分支的业务逻辑（如状态码映射、地区分级、评分等级），应该用搜索型 CASE WHEN，而不是靠堆 IIF。
什么情况下 IIF 才真比 CASE 更合适？
只有同时满足这四点，IIF 才算“简化”而非“炫技”：
- 判断逻辑确实是非此即彼（例如
is_deleted = 1/is_deleted = 0），不存在第三种有效状态 - 不涉及
IN、BETWEEN、IS NULL、函数调用（如LEN(name) > 0）等复杂谓词 - 目标环境确定是 SQL Server（
IIF在 PostgreSQL / MySQL / Oracle 中根本不存在） - 团队规范允许，且 DBA 不反对——有些生产环境明确禁用
IIF，认为它削弱了 SQL 的可扫描性和跨平台迁移能力
合理示例：IIF(order_amount > 0, 'valid', 'invalid')
反例（应改用 CASE）：IIF(shipping_date IS NULL, 'pending', IIF(DATEDIFF(day, order_date, GETDATE()) > 30, 'delayed', 'on_time'))
真正容易被忽略的一点：IIF 的 else_value 会吞掉所有“未覆盖情况”，包括 NULL 输入和意外值。而搜索型 CASE WHEN 可以显式写出 WHEN status IS NULL THEN 'unknown'，语义更精确，也更容易加监控告警。别为了少打几个字母，放弃对空值和异常分支的掌控力。
