EF Core使用filename过滤查询超时但SSMS执行快速的问题咨询

问题排查方案 #

1. 校验字段与参数类型匹配性 #

这是此类问题最高发的原因：

• 确认数据库Documents.Document表中FileName字段的实际类型，若该字段为varchar类型，而EF Core传入的参数@__fileName_1为nvarchar(1024)类型，会触发SQL Server隐式类型转换，导致FileName字段上的索引完全失效，触发全表扫描引发超时。
• SSMS执行时如果参数类型和字段类型匹配，就会正常走索引，因此出现两边执行速度差异。
• 修复方案：在实体映射配置中显式指定FileName字段的类型与数据库完全一致：

modelBuilder.Entity<Document>()
    .Property(d => d.FileName)
    .HasColumnType("varchar(1024)"); // 替换为你数据库中该字段的实际类型与长度

2. 排查参数嗅探导致的执行计划不匹配 #

SQL Server的参数嗅探机制可能为EF Core的查询生成了不合适的缓存执行计划：

• 测试环境可执行DBCC FREEPROCCACHE清空缓存计划后重试，若问题消失即可确认原因。
• 可通过EF Core的查询标签功能添加重编译提示临时验证：

var totalCount = await query.TagWith("OPTION (RECOMPILE)").CountAsync();

3. 抓取CountAsync实际执行的SQL校验 #

你贴出的SQL是列表查询生成的语句，而非CountAsync执行的语句，需先确认计数语句本身的合理性：

• 开启EF Core日志输出，抓取CountAsync对应的实际SQL，放到SSMS中执行验证速度：

// 程序启动时配置EF Core日志输出
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.LogTo(Console.WriteLine, Microsoft.Extensions.Logging.LogLevel.Information);
}

• 若生成的计数语句保留了不必要的排序、冗余关联，可通过简化查询结构优化：

var totalCount = await query.Select(d => d.Id).CountAsync();

4. 校验连接配置一致性 #

SSMS与.NET客户端的默认连接配置存在差异，可能导致执行计划不同：

• 确认ARITHABORT参数配置，SSMS默认开启该参数，而System.Data.SqlClient默认关闭，不同配置会导致SQL Server选择不同的执行计划。
• 可在连接字符串中添加ArithAbort=True验证问题是否解决：

Data Source=你的数据库实例;Initial Catalog=你的库名;Integrated Security=True;ArithAbort=True;

5. 排查锁阻塞问题 #

执行计数语句时可通过SSMS的活动监视器或系统存储过程检查是否存在锁阻塞：

EXEC sp_who2
-- 查看BlkBy列，若存在非空值即表示对应会话被其他会话阻塞

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