EntityFramework Core 中 SQL Server 查询生成的一个特殊案例解析

在使用 EntityFramework Core 9.0.1 版本与 SQL Server 数据库交互时，开发人员可能会遇到一个有趣的查询生成问题。当使用 .Contains() 方法查询一个空集合时，EF Core 生成的 SQL 语句可能会导致意外的数据库错误。

问题现象

考虑以下典型的 LINQ 查询场景：

List<string> names = null;
var col = db.Foo.Where(f => names.Contains(f.Name)).ToList();

这段代码在本地执行时会抛出 NullReferenceException，但在通过 EF Core 转换为 SQL 查询时，会生成如下 SQL 语句：

SELECT [f].[Id], [f].[Name]
FROM [Foo] AS [f]
WHERE [f].[Name] IN (
    SELECT [n].[value]
    FROM OPENJSON(NULL) AS [n]
)

这个查询会在 SQL Server 上执行失败，错误信息表明存在排序规则冲突： "无法在等于操作中解决 Latin1_General_BIN2 和 SQL_Latin1_General_CP1_CI_AS 之间的排序规则冲突"

技术背景

这个问题源于 EF Core 在处理空集合时的查询转换机制。当遇到集合包含操作(.Contains)时，EF Core 会将其转换为 SQL 中的 IN 子句。对于空集合，EF Core 使用 OPENJSON 函数来处理，而传递 NULL 值给 OPENJSON 会导致 SQL Server 使用默认的 Latin1_General_BIN2 排序规则，与表中字段的实际排序规则产生冲突。

解决方案

开发人员可以采用以下两种推荐方式避免此问题：

1. 使用空集合替代 null：

var names = new List<string>(); // 显式初始化空集合

2. 在查询中添加 null 检查：

var col = db.Foo.Where(f => names != null && names.Contains(f.Name)).ToList();

深入理解

从技术实现角度看，EF Core 的这种行为实际上是合理的，因为代码在本地执行时同样会抛出异常。数据库错误只是这种异常情况在 SQL 层面的表现。开发人员应该像处理普通代码一样，在查询中加入必要的 null 检查，这是更健壮的编程实践。

最佳实践建议

1. 在使用集合进行 LINQ 查询时，始终考虑集合可能为 null 的情况
2. 对于可能为 null 的集合参数，在方法入口处进行验证或提供默认值
3. 考虑使用空集合而不是 null 来表示"没有元素"的状态
4. 在复杂查询中，显式处理边界条件可以使代码更清晰且更易于维护

这个问题虽然看起来像是框架的"bug"，但实际上反映了编程中常见的边界条件处理问题。通过遵循上述实践，可以避免类似问题并编写出更健壮的数据库访问代码。