EF Core表值参数性能远差于直接T-SQL的原因与优化方法

我定义了如下自定义表类型：

CREATE TYPE [dbo].[myTable] AS TABLE
(
    my_id    BIGINT, 
    my_name  VARCHAR(100),
    my_value VARCHAR(100)
)
GO

同时创建了使用该类型作为输入参数的存储过程：

CREATE OR ALTER procedure my_merge_sp
    (@downloaded_records [myTable] READONLY,
     @last_updated_on    DATETIME,      
     @last_updated_by    VARCHAR(128))
AS
BEGIN
    -- DO STUFF
END

在SSMS中，声明myTable实例并插入20万条记录后调用存储过程，耗时仅2秒；但在EF Core中，我使用匹配该类型结构的DataTable创建SqlParameter并传入相同20万条记录时，执行存储过程的命令超时（命令超时已设为120秒）。另外测试过用EF Core传入50条记录，耗时1秒且执行正常，说明EF Core配置无问题。

请问EF Core与SSMS的处理存在哪些关键差异导致性能差距如此巨大？有哪些技巧可以让EF Core的性能接近SSMS？

关键性能差异原因 #

• 数据传输机制不同：SSMS使用TDS（Tabular Data Stream）协议的批量优化传输模式，直接将表数据以高效的二进制格式批量发送到SQL Server；而EF Core默认使用DataTable作为表值参数时，会逐行序列化数据，未启用批量传输优化，导致序列化和网络传输开销暴增。
• 元数据匹配度差异：EF Core创建的SqlParameter如果没有显式指定与自定义表类型完全匹配的元数据（比如列的精确类型、长度），SQL Server会对传入的数据做额外的类型转换或验证，增加计算开销。
• 执行计划与参数嗅探：SSMS调用存储过程时的参数上下文可能触发更优的执行计划，而EF Core的调用方式（比如参数包装形式）可能导致SQL Server生成不同的执行计划，或触发不利的参数嗅探行为。
• 冗余开销：EF Core作为ORM框架，在构建命令、处理参数过程中会产生额外的对象创建、校验等开销，在大数据量下这些开销会被放大。

性能优化技巧 #

• 改用SqlBulkCopy预加载临时表：先通过SqlBulkCopy将20万条数据批量插入到SQL Server的临时表（比如#tempTable），再修改存储过程从临时表读取数据，避免直接传递大型表值参数的序列化和传输开销。
• 使用SqlDataRecord批量构建表值参数：替代DataTable，手动创建SqlDataRecord集合并通过SqlParameter的Value传入，这种方式更接近SSMS的批量传输逻辑，减少序列化开销。示例代码：

  var tvpParam = new SqlParameter("@downloaded_records", SqlDbType.Structured)
  {
      TypeName = "[dbo].[myTable]",
      Value = GetSqlDataRecords() // 返回IEnumerable<SqlDataRecord>
  };
  

• 显式指定表值参数元数据：创建SqlParameter时必须明确设置TypeName为自定义表类型的完整名称（[dbo].[myTable]），同时确保DataTable的列类型、长度与自定义表类型完全一致（比如my_name对应VARCHAR(100)而非string默认的NVARCHAR）。
• 优化EF Core命令执行：使用ExecuteSqlRaw直接执行存储过程调用，跳过EF Core的LINQ解析等额外开销；同时可以在存储过程中添加OPTION (RECOMPILE)（如果是执行计划问题），或强制使用已验证的最优执行计划。
• 调整EF Core配置：关闭不必要的跟踪（比如AsNoTracking()），减少ORM的对象管理开销；同时确保数据库连接使用连接池，避免频繁创建连接的开销。

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