T-SQL中IN (NULL)是否可稳定返回空行？是否属于不良实践？

IN (NULL)是否可以稳定实现无结果返回？ #

常规生产环境下可以稳定返回空结果，行为符合预期：

• T-SQL遵循ANSI SQL的三值逻辑（TRUE/FALSE/UNKNOWN），col IN (val1, val2)本质是col = val1 OR col = val2的语法糖。当列表仅包含NULL时，表达式展开为col = NULL，而任意值（包括NULL本身）与NULL做等值比较的结果都是UNKNOWN。WHERE子句仅会保留判定结果为TRUE的行，因此无论被查询的列存储的是普通值还是NULL，该条件都不会命中任何行。
• 唯一的例外场景是手动将会话参数ANSI_NULLS设置为OFF：此时NULL = NULL会被判定为TRUE，列中存储的NULL值会被IN (NULL)匹配到。但该设置早已被微软标记为废弃特性，当前所有主流支持的SQL Server版本、Azure SQL全系列产品均默认强制开启ANSI_NULLS且不允许关闭，生产环境几乎不会触发该例外。

你提到的微软文档警示的"IN/NOT IN搭配NULL产生非预期结果"，最常见的场景是NOT IN (NULL)——该写法会导致整个条件永久返回UNKNOWN，永远返回空结果，和多数开发者"返回不在列表内的值"的直觉完全相悖，属于高频踩坑点，和你测试的IN (NULL)场景逻辑不同，但也印证了NULL与IN搭配本身容易出现认知偏差。

这种写法是否属于不良实践？ #

属于典型的不良实践，不推荐在生产系统中使用，核心原因如下：

• 语义严重不匹配：90%以上的开发者看到IN (NULL)的第一反应是"要查询列值为NULL的行"，和你实际想要的"空列表入参时不返回任何行"的逻辑完全不符，后续维护人员极容易误改逻辑引发故障。
• 依赖边缘规则生效：IN (NULL)返回空结果是三值逻辑推导出来的边缘效果，并非语法设计时针对"空列表兜底"提供的官方能力，哪怕未来出现兼容级别调整的概率极低，也存在不必要的隐含风险。
• 提升排查成本：出现SQL逻辑问题、性能问题时，排查人员很难第一时间意识到IN (NULL)是人为添加的"恒假条件"，会额外增加问题定位的时间成本。

如果你不想保留原来"空列表抛异常"的逻辑，更合理的替代方案是直接生成语义明确的恒假条件WHERE 1 = 0，该写法在所有SQL环境下行为完全一致，没有任何歧义，任何开发者看到都能立刻理解这是"不返回任何行"的显式逻辑。

内容的提问来源于stack exchange，提问作者MadMaxIV