Entity Frameworkのクエリは遅いが、SqlQueryの同じSQLは速い

Entity Framework Code-Firstと.NET Frameworkバージョン4を使用した非常に単純なクエリに関連する、非常に奇妙なパフォーマンスがいくつかあります。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を通じて実行されると、ほぼ瞬時に実行されます。SqlQuery関数を使用するようにC＃コードを変更すると、5〜10ミリ秒で実行されます。

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

したがって、まったく同じSQLであり、結果のエンティティはどちらの場合も変更が追跡されますが、2つの場合のパフォーマンスは大きく異なります。何ができますか？

それを見つけた。SQLデータ型の問題であることがわかりました。SomeStringPropデータベースの列はvarcharでしたが、EFでは、.NET文字列型はnvarcharであると想定しています。DBが比較を行うためのクエリ中に結果として生じる変換プロセスは、長時間かかります。私はEF Profが私をここで少し誤解させていたと思います、実行されているクエリのより正確な表現は次のようになります：

 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で作成したクエリを遅くする理由は、null許容スカラーとnull許容スカラーを比較することでした。

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

信じられないほどの結果をもたらします。完了するのにわずか50msかかりました。EFのバグである可能性があります。

流れるようなマッピングを使用しIsUnicode(false)ている場合は、構成の一部として使用して同じ効果を得ることができます-

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

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

同じ問題がありましたが（SQLマネージャーから実行するとクエリが高速になります）、EFから実行するとタイムアウトになります。

エンティティ（ビューから作成されたもの）に誤ったエンティティキーがあることがわかりました。そのため、エンティティには同じキーを持つ重複行があり、背景でグループ化する必要があったと思います。

また、複雑なefクエリでこれに遭遇しました。6秒のefクエリを生成する1秒未満のsqlクエリに削減した1つの修正は、遅延読み込みをオフにすることでした。

この設定（ef 6）を見つけるには、.edmxファイルに移動し、[プロパティ]-> [コード生成]-> [遅延読み込み有効]を確認します。falseに設定します。

パフォーマンスが大幅に向上しました。

私にもこの問題がありました。私の場合の犯人はSQL-Server パラメータの盗聴だったことがわかりました。

私の問題が実際にパラメータースニッフィングが原因であった最初の手がかりは、「set arithabort off」または「set arithabort on」でクエリを実行すると、Management Studioで実行時間が大幅に異なることでした。これは、ADO.NETではデフォルトで「set arithabort off」が使用され、Management Studioではデフォルトで「set arithabort on」が使用されるためです。クエリプランキャッシュは、このパラメーターに応じて異なるプランを保持します。

クエリのクエリプランのキャッシュを無効にしました。解決策はここにあります。