为什么EF Core的DbSet通过LINQ查询不到实际存在的记录？

核心差异根源 #

你遇到的问题本质是EF LINQ查询执行逻辑和即时窗口对比逻辑的运行环境完全不同：

• 你写的SetParty.Where(x => x.Name == name).FirstOrDefault()属于LINQ to Entities查询，EF会将其翻译为SQL语句在数据库端执行，查询过滤逻辑完全受数据库规则控制。
• 即时窗口中的==对比是在.NET运行时的内存中执行，属于C#原生的字符串序数比较，不受数据库规则影响。

具体可能原因 #

1. 数据库排序规则（Collation）不匹配 #

这是最符合你描述的场景：

• 数据库端字符串比较受字段/库/表的排序规则控制，会自动处理大小写、重音、特殊空白字符（如你猜测的非换行空格U+00A0、全角空格等）、尾部空格的匹配逻辑，和C#逐码点对比的规则完全不一致。
• 你在即时窗口对比返回true，只能证明内存中两个字符串的Unicode码点完全一致，但数据库端的排序规则可能判定二者不相等，导致SQL查询返回空。

2. 全局查询过滤器被触发 #

如果你在DbContext中配置了全局查询过滤器（比如软删除过滤、多租户过滤等）：

• LINQ to Entities查询会自动应用过滤器，符合过滤条件的记录会被直接剔除。
• 你在即时窗口中用SystemCore_EnumerableDebugView访问数据时，会触发全表数据加载到上下文本地缓存，全局过滤器不会对已经加载到内存的缓存数据生效，因此你可以拿到目标记录。

3. 未提交事务的隔离级别问题 #

如果这两条异常记录是你在同一个事务中刚导入的，且查询时事务还未提交：

• 默认的读提交隔离级别下，LINQ查询到数据库端执行时读不到未提交的新记录。
• 如果你在断点停留期间事务刚好完成提交，或者加载全表数据时触发了事务内的读取，就能拿到目标记录。

验证与解决方法 #

• 第一步：开启EF敏感数据日志，打印该LINQ查询生成的原生SQL，直接拿到数据库中执行：
  • 如果原生SQL也查不到记录，100%是排序规则问题，你可以在查询时显式指定匹配的排序规则，示例：

    party = SetParty.Where(x => EF.Functions.Collate(x.Name, "Chinese_PRC_CI_AS") == name).FirstOrDefault();
    

    也可以直接修改数据库Name字段的排序规则为你需要的匹配规则。
  • 如果原生SQL可以查到记录，排除排序规则问题，继续下一步验证。
• 第二步：在原LINQ查询中添加IgnoreQueryFilters()方法临时关闭全局过滤器，测试是否能查到记录：

  party = SetParty.IgnoreQueryFilters().Where(x => x.Name == name).FirstOrDefault();
  

  如果能查到，说明是全局过滤器的问题，检查两条异常记录是否满足过滤器的匹配条件（比如是否被标记为已删除、租户ID不匹配等）。
• 第三步：数据导入阶段增加特殊字符清洗逻辑，提前把非标准空白、不可见控制字符替换为标准字符，从根源避免字符串匹配异常。

即时窗口对比正常的原因解释 #

你在即时窗口中使用SystemCore_EnumerableDebugView访问Items时，会强制EF枚举整个DbSet的所有数据，将全表记录加载到上下文的本地缓存中，此时你做的==对比是纯内存层面的C#原生字符串比较，完全绕过了数据库排序规则、全局查询过滤器、事务隔离级别的限制，只要两个字符串的Unicode码点完全一致就会返回true，和之前的数据库端LINQ查询不属于同一个执行逻辑。

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