奇怪的 WHERE col = NULL 行为

Question

这是我们的一位开发人员向我提出的问题。他偶然发现了一个旧的存储过程，该过程多次使用“WHERE col = NULL”。 执行存储过程时，它会返回数据。

如果手动执行存储过程内的查询，它将不会返回数据，除非将“WHERE col = NULL”引用更改为“WHERE col IS NULL” 。

谁能解释这种行为？

Answer 1

这是设计使然：如果您将任何内容与 null 进行比较，则其计算结果为 unknown。任何未知的逻辑本身就是未知。因此任何带有 anything = null 的语句都将始终为 false。

重要的区别在于这两个结构之间：

1 = null --> unknown
1 is null --> false

所以：

1 = null or 1=1 --> unknown (false)
1 is null or 1=1 --> true

正如您所看到的，unknown 污染了整个表达式。

根据评论，更好的答案可能是检查 ANSI_NULL，其中：

SELECT SESSIONPROPERTY ('ANSI_NULLS')

如果返回 false，则 = null 构造将像 is null 一样工作code>：

set ansi_nulls on -- default
SELECT SESSIONPROPERTY ('ANSI_NULLS') -- 1
select 1 where not null = 1 -- no rows returned
set ansi_nulls off
SELECT SESSIONPROPERTY ('ANSI_NULLS') -- 0
select 1 where not null = 1 -- returns a row

默认设置是 ansi_nulls on，但看到它关闭的情况很不常见。存储过程确实会记住创建时的设置：

set ansi_nulls off
go
create procedure dbo.TestNulls as select 1 where not null = 1
go
set ansi_nulls on
exec dbo.TestNulls -- Still prints a row

您可以通过从 SSMS 编写过程脚本来检查保存的设置。

Answer 2

好吧，我想我应该回答这个问题：

检查 ANSI_NULLS 设置

Answer 3

在 SQL 中，X = NULL 将始终计算为 false，因为 NULL 表示不存在数据，因此无法判断它是否等于“另一个”不存在数据（NULL = NULL 是假的）。这就是 IS 关键字存在的原因......