Azure SQL 在参数化查询 NVARCHAR(4000) 上性能缓慢

Question

我意识到在使用 Azure SQL 数据库时使用 EntityFramework 生成的参数化查询时的性能差异。

我有一个带有 varchar(30) 主键的表，当我尝试使用主键从该表中获取值时，EntityFramework 使用 NVARCHAR(4000) 作为数据类型创建参数化查询。

DECLARE @p__linq__0 nvarchar(4000)
SET @p__linq__0 ='ehenurqp0kpql76kjsw3'

select * from mediacontentreferences where mediacontentreferenceid=@p__linq__0

这会在 Azure SQL 数据库上生成一个非常奇怪的执行计划。

这是非常无效的，因为它使用了查看整个表的索引扫描。

如果我使用具有正确数据类型的参数，执行计划将使用主键索引。

DECLARE @p__linq__1 varchar(30)
SET @p__linq__1 ='ehenurqp0kpql76kjsw3'

select * from mediacontentreferences where mediacontentreferenceid=@p__linq__1

如果我在本地 SQL 服务器上使用第一个查询，执行计划会将 NVARCHAR(4000) 转换为 VARCHAR(30) 并使用主键索引。

这看起来像是 Azure SQL 服务器上的执行计划计算中的一个缺陷。

是否有可能改变实体框架创建查询的行为？

我已经阅读了几篇关于此的文章，但没有找到解决方案。

Why does code first/EF use 'nvarchar(4000)' for strings in the raw SQL command?

Why does Entity Framework generate large parameters? How can they be reduced?

Answer 1

您必须为列指定正确的数据类型，而不是 EF 在生成查询时将声明具有正确数据类型的参数。只需将其添加到您的 DbContext：

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Entity<mediacontentreferences >().Property(e => e.mediacontentreferenceid).HasColumnType("varchar");
    }