iif是sql server 2012+引入的case when语法糖，仅支持三参数二元判断，不跨数据库兼容；应避免嵌套、where滥用、null错误比较及非确定性场景，多条件或需可移植时优先用case。
SQL Server 里 IIF 的基本用法和替代方案
IIF 是 SQL Server 2012+ 引入的简写函数，本质是 CASE WHEN 的语法糖。它只接受三个参数：IIF(条件, 真值, 假值)，返回标量值。不是所有数据库都支持——MySQL、PostgreSQL、SQLite 都没有 IIF，强行用会报错 Invalid column name 'IIF' 或类似提示。
实操建议：
- 确认数据库版本：运行
SELECT @@VERSION，低于 SQL Server 2012 就别试了 - 别在 WHERE 或 ON 子句里滥用：虽然语法允许，但
IIF(grade > 90, 1, 0) = 1不如直接写grade > 90清晰且可走索引 - 嵌套
IIF很快变难读，两层以上建议换回CASE - 注意数据类型隐式转换：比如
IIF(is_active = 1, 'Y', 0)会让整个结果转成varchar（因为 'Y' 是字符串），可能引发后续计算或比较异常
什么时候该用 IIF，而不是 CASE
适合场景非常明确：单条件、双分支、表达式级判断，且追求语句紧凑。比如生成状态标签、做简单数值映射、拼接描述字段。
常见错误现象：把多条件逻辑硬塞进 IIF，例如想实现“优秀/良好/及格/不及格”四档，写成 IIF(score>=90,'A',IIF(score>=80,'B',IIF(...))) —— 这不仅难维护，SQL Server 查询优化器也更难生成高效执行计划。
实操建议：
- 仅当逻辑确实是“是/否”“开/关”“成功/失败”这类二元判断时优先用
IIF - 涉及 NULL 判断要小心：
IIF(col IS NULL, 'missing', col)没问题，但IIF(col = NULL, ...)永远为 false（因为NULL = NULL不成立） - 性能上和等价的
CASE几乎无差别，别指望它提速，它只是少打几个字
IIF 在 SELECT 和计算列中的典型误用
很多人试图在定义计算列或视图时用 IIF 做业务规则封装，比如：ALTER TABLE orders ADD status_desc AS IIF(status = 'P', 'Processing', 'Done')。看起来干净，但隐患不少。
使用场景限制：
- 计算列若含
IIF，默认是非持久化的，每次查询都重新计算；加PERSISTED要求所有参数表达式都是确定性的——而IIF本身是确定性函数，但若引用了非确定性函数（如GETDATE()）就失效 - 导出到 Excel 或对接 BI 工具时，某些驱动不识别
IIF，报Invalid token，换成CASE就通了 - SSIS 或链接服务器查询远程表时，
IIF可能被下推失败，导致全表拉到本地再计算，拖慢性能
兼容旧版或跨数据库的稳妥写法
如果你的代码要跑在多个环境（比如开发用 LocalDB，测试用 Azure SQL，生产用 SQL Server 2016），或者团队里有人习惯写标准 SQL，那就绕过 IIF，统一用 CASE。
示例对比：
SELECT name, IIF(age >= 18, 'Adult', 'Minor') AS category -- 简洁但有局限 FROM users;
等价但更通用的写法：
SELECT name, CASE WHEN age >= 18 THEN 'Adult' ELSE 'Minor' END AS category FROM users;
关键点在于：CASE 明确、标准、可移植，且支持多分支、WHEN 中可写任意布尔表达式（包括子查询），而 IIF 就是个带限制的快捷键——用得舒服的前提是你清楚它的边界在哪。
最容易被忽略的是部署阶段：CI/CD 流水线里如果混用不同版本 SQL Server 实例，一个 IIF 就能让整个脚本在旧实例上卡住，报错信息还容易被日志截断，只显示 Incorrect syntax near 'IIF'。
