为何SQL中用!= 'NULL'替代IS NOT NULL仍能正常运行？

这问题确实有点反直觉，毕竟我们都清楚SQL里的NULL是未知值，绝非字符串'NULL'。能出现这种“不符合常识却能跑通”的情况，大概率是下面几个原因之一：

• 你的数据表中真的存了字符串'NULL'
  这是最常见的场景。很多时候，前端程序、数据导入脚本甚至手动录入数据时，会把“空值”用字符串'NULL'填充，而非使用SQL标准的NULL值。这时候你写的emailaddress1 != 'NULL'，本质是在过滤掉那些字段值被存成字符串'NULL'的记录，刚好和你想要排除“空值”的需求达成了一致——但你处理的是字符串，不是真正的SQL NULL。

• ANSI_NULLS配置的特殊兼容逻辑
  SQL Server有个会话级配置ANSI_NULLS：

  • 当它设为ON（默认值）时，任何和NULL的比较（比如= NULL或!= NULL）都会返回UNKNOWN，不会过滤任何行；
  • 当它设为OFF时，旧版兼容模式会允许= NULL在字段为真正NULL时返回TRUE，!= NULL返回FALSE。而如果你的条件是!= 'NULL'（字符串），真正的NULL和字符串'NULL'比较时，在ANSI_NULLS OFF下会返回TRUE，所以这类行也会被保留。不过这种情况现在很少见，微软已经不推荐使用ANSI_NULLS OFF了。

• 混淆了SSMS显示的NULL和实际存储值
  有时候SSMS查询结果里显示的NULL，会让你误以为是SQL NULL，但如果字段是字符串类型，存储的是'NULL'字符串，SSMS不会特意区分显示——除非你开启了“显示字符串NULL”的特殊选项。你可以直接执行SELECT emailaddress1 FROM FilteredContact WHERE emailaddress1 = 'NULL'验证，看看是否有结果返回，就能确认这一点。

关键提醒 #

你提到的IS NOT NULL才是判断SQL NULL的标准写法，!= 'NULL'只是巧合适配了当前的数据情况。如果之后数据表中出现真正的SQL NULL，原代码就无法过滤掉这些行了，建议尽快改成标准写法。

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