C# 为什么EF6 LINQ不能生成正确的；是空的；用于空字符串变量比较的SQL？

我们有一个基于EDMX的EF6应用程序，我们希望在其中运行这样的LINQ查询

string category = ... // comes from somewhere and equals to null
context.Product.Where(e => e.Category == category).ToArray();

我看到的问题是，生成的SQL在where子句中包含一个

[table].[Category]=@p..

，而不管变量

Category

是否为

null

。因此，在一天结束时，如果变量为

null

，查询将不返回任何结果，而不是生成适当的

is null

条件并返回适当的行

我已经使用显式的

e=>e.Category==null

表达式进行了测试，它确实按照预期生成了

is null

我还检查了EDMX和SQL，相应的

Category

列在这两个位置都可以为空，所以这可能不是问题所在

---

如果有任何帮助，我们将不胜感激。

请尝试将

context.Configuration.UseDatabaseNullSemantics

设置为

false

。这是影响上述行为的属性

---

请参阅文档

是否有任何原因不在LINQ端执行null检查？我的意思是，这并不是说你只能有一个WHERE语句。你知道你可以把他们连在一起，也可以是动态的吗？我的标准基本上是做空检查，然后只在t不为空时添加where子句。否则，这看起来确实像是github端的bug-opentickets。他们至少应该生成一个空值。这个期望是错误的，会违反SQL的三值逻辑，并且实际上会让那些期望空值不返回任何内容的开发人员感到惊讶。正如您所发布的，EF（和大多数ORM）生成参数化查询。查询不会在每次值更改时更改。

Category=@p1

与

Category=@p1非常不同，或者Category也为NULL

，从而导致非常不同的执行计划和性能。EF（或任何ORM）不能随意选择较宽的查询而不是较窄的查询，因为它会返回意外的结果，并导致性能差得多。您可能会争辩说，对于那些希望ORM不使用SQL语义的人来说，应该有一个开关，但当其他开发人员试图理解查询为何不能正常运行时，这将导致维护噩梦expected@PanagiotisKanavos谢谢你的澄清，这是有道理的。然而，我所期望的是EF是聪明的，因此在解析我的LINQ表达式时，它会注意到表达式

category

基本上是

null

，因此在这种情况下，它应该生成

[category]is null

where子句。似乎EF不会在本地计算这些表达式，而只是生成一个参数化查询。@ZoltaánTamási我希望EF（或任何ORM）不会违反SQL的行为。您要求EF使用C#的空逻辑而不是SQL，即使它显然是在查询SQL数据库。