实体框架查询速度很慢，但是SqlQuery中的相同SQL速度很快

我看到一些非常奇怪的性能，它们与使用.NET Framework版本4的Entity Framework Code-First进行的非常简单的查询有关。LINQ2Entities查询如下所示：

 context.MyTables.Where(m => m.SomeStringProp == stringVar);

这将花费3000毫秒以上的时间来执行。生成的SQL看起来非常简单：

 SELECT [Extent1].[ID], [Extent1].[SomeStringProp], [Extent1].[SomeOtherProp],
 ...
 FROM [MyTable] as [Extent1]
 WHERE [Extent1].[SomeStringProp] = '1234567890'

通过Management Studio运行时，该查询几乎立即运行。当我更改C＃代码以使用SqlQuery函数时，它将在5到10毫秒内运行：

 context.MyTables.SqlQuery("SELECT [Extent1].[ID] ... WHERE [Extent1].[SomeStringProp] = @param", stringVar);

因此，使用完全相同的SQL，在两种情况下，生成的实体都会进行更改跟踪，但是两者之间的性能差异很大。是什么赋予了？

找到了。原来这是SQL数据类型的问题。SomeStringProp数据库中的列是varchar，但是EF假定.NET字符串类型是nvarchars。在查询过程中，数据库进行比较需要花费很长时间。我认为EF教授在这里误导了我，正在运行的查询的更准确表示如下：

 SELECT [Extent1].[ID], [Extent1].[SomeStringProp], [Extent1].[SomeOtherProp],
 ...
 FROM [MyTable] as [Extent1]
 WHERE [Extent1].[SomeStringProp] = N'1234567890'

因此，最终的解决方法是注释代码优先模型，以指示正确的SQL数据类型：

public class MyTable
{
    ...

    [Column(TypeName="varchar")]
    public string SomeStringProp { get; set; }

    ...
}

减慢我在EF中进行查询的原因是将不可为空的标量与可为空的标量进行比较：

long? userId = 10; // nullable scalar

db.Table<Document>().Where(x => x.User.Id == userId).ToList() // or userId.Value
                                ^^^^^^^^^    ^^^^^^
                                Type: long   Type: long?

该查询花费了35秒。但是这样的微小重构：

long? userId = 10;
long userIdValue = userId.Value; // I've done that only for the presentation pursposes

db.Table<Document>().Where(x => x.User.Id == userIdValue).ToList()
                                ^^^^^^^^^    ^^^^^^^^^^^
                                Type: long   Type: long

给出了令人难以置信的结果。只需50毫秒即可完成。这很可能是EF中的错误。

如果您使用的是流畅的映射，则可以将其IsUnicode(false)用作配置的一部分以达到相同的效果-

http://msdn.microsoft.com/en-us/data/jj591617.aspx#1.9

http://msdn.microsoft.com/zh-cn/library/gg696416%28v=vs.103%29.aspx

我遇到了同样的问题（从SQL管理器执行查询时查询很快），但是从EF执行时超时到期。

原来，实体（从视图创建）具有错误的实体键。因此，该实体具有使用相同键的重复行，我想它必须在背景上进行分组。

我还遇到了一个复杂的ef查询。对我来说，将6秒的ef查询减少到它生成的2秒以下的sql查询的一个解决方法是关闭延迟加载。

要找到此设置（ef 6），请转到.edmx文件，然后在“属性”->“代码生成”->“启用延迟加载”中查找。设置为false。

对我来说，性能有很大的提高。

我也有这个问题。事实证明，在我的案例中，罪魁祸首是SQL-Server 参数嗅探。

我的问题实际上是由于参数嗅探引起的第一个线索是，在“ set arithabort off”或“ set arithabort on”下运行查询在Management Studio中产生了截然不同的执行时间。这是因为ADO.NET默认情况下使用“关闭arithabort”，而Management Studio默认使用“打开arithabort”。查询计划缓存根据此参数保留不同的计划。

我禁用了查询的查询计划缓存，您可以在此处找到解决方案。