EF Core执行LINQ查询报超时异常且未生成WHERE条件问题排查

超时、查询无WHERE子句的核心原因是EF Core客户端评估陷阱：
你使用的string.Equals(string, StringComparison)重载中，传入StringComparison.OrdinalIgnoreCase的写法无法被SQL Server提供器翻译为SQL侧的过滤逻辑，EF Core会自动降级为客户端评估——即直接生成不带WHERE条件的SQL，把UserStandby表全量12万余条记录全部加载到应用内存中，再在内存里完成大小写不敏感的匹配。这种全表拉取的逻辑数据量稍大就会触发超时，你之前在ECUserId字段上创建的索引完全不会生效，因为过滤根本没在数据库侧执行。
额外纠正一个认知偏差：你提到的排序规则SQL_Latin1_General_CP1_CI_AS中，CI是*Case Insensitive（大小写不敏感）*的缩写，AS是重音敏感，该排序规则本身就默认不区分大小写，你标注的“大小写敏感”是记忆错误，后缀为CS的排序规则才是大小写敏感。

• 优先使用EF Core可正常翻译的相等判断语法，去掉无法翻译的StringComparison参数。因为字段本身就是大小写不敏感的排序规则，数据库侧的=比较默认就会忽略大小写，完全不需要额外在LINQ层指定IgnoreCase逻辑，修改后的代码如下：

string ECUserId = "TN504060";
var userStandby = await _context.UserStandby
    .Where(standBy => standBy.ECUserId == ECUserId)
    .FirstOrDefaultAsync();

• 如果你的字段实际使用的是大小写敏感（CS后缀）的排序规则，需要显式指定数据库侧的比较规则，不要使用会触发客户端评估的StringComparison重载，可直接在模型配置中给字段映射对应不区分大小写的排序规则，配置后EF Core会自动生成符合索引命中规则的SQL：

// 在DbContext的OnModelCreating方法中添加配置
modelBuilder.Entity<UserStandby>()
    .Property(p => p.ECUserId)
    .UseCollation("SQL_Latin1_General_CP1_CI_AS");

• 修改完成后验证生成的SQL，可通过ToQueryString()方法或者EF Core日志确认SQL中包含WHERE [ECUserId] = @__ECUserId_0形式的过滤条件，此时你之前创建的非聚集索引会被正常命中，不会再出现全表加载导致的超时问题。

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