Entity Framework-Abfrage langsam, aber dasselbe SQL in SqlQuery ist schnell

Ich sehe eine wirklich seltsame Leistung im Zusammenhang mit einer sehr einfachen Abfrage mit Entity Framework Code-First mit .NET Framework Version 4. Die LINQ2Entities-Abfrage sieht folgendermaßen aus:

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

Die Ausführung dauert über 3000 Millisekunden. Das generierte SQL sieht sehr einfach aus:

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

Diese Abfrage wird fast sofort ausgeführt, wenn sie über Management Studio ausgeführt wird. Wenn ich den C # -Code ändere, um die SqlQuery-Funktion zu verwenden, wird er in 5-10 Millisekunden ausgeführt:

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

Bei genau derselben SQL werden die resultierenden Entitäten in beiden Fällen nachverfolgt, aber es gibt einen wilden Leistungsunterschied zwischen den beiden. Was gibt?

Fand es. Es stellt sich heraus, dass es sich um ein Problem mit SQL-Datentypen handelt. Die SomeStringPropSpalte in der Datenbank war ein Varchar, aber EF geht davon aus, dass .NET-Zeichenfolgentypen nvarchars sind. Der resultierende Übersetzungsprozess während der Abfrage der DB, um den Vergleich durchzuführen, dauert lange. Ich glaube, EF Prof hat mich hier ein bisschen in die Irre geführt. Eine genauere Darstellung der ausgeführten Abfrage wäre die folgende:

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

Der resultierende Fix besteht also darin, das Code-First-Modell mit Anmerkungen zu versehen und den richtigen SQL-Datentyp anzugeben:

public class MyTable
{
    ...

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

    ...
}

Der Grund für die Verlangsamung meiner in EF gestellten Abfragen war der Vergleich nicht nullbarer Skalare mit nullbaren Skalaren:

long? userId = 10; // nullable scalar

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

Diese Abfrage dauerte 35 Sekunden. Aber so ein winziges Refactoring:

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

gibt unglaubliche Ergebnisse. Die Fertigstellung dauerte nur 50 ms. Es ist möglich, dass es sich um einen Fehler in EF handelt.

Wenn Sie das fließende Mapping verwenden, können Sie es IsUnicode(false)als Teil der Konfiguration verwenden, um den gleichen Effekt zu erzielen.

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

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

Ich hatte das gleiche Problem (die Abfrage ist schnell, wenn sie von SQL Manager ausgeführt wird), aber wenn sie von EF ausgeführt wird, läuft das Zeitlimit ab.

Es stellt sich heraus, dass die Entität (die aus der Ansicht erstellt wurde) falsche Entitätsschlüssel hatte. Die Entität hatte also doppelte Zeilen mit denselben Schlüsseln, und ich denke, sie musste im Hintergrund gruppiert werden.

Ich bin auch auf eine komplexe ef-Abfrage gestoßen. Ein Fix für mich, der eine 6-Sekunden-EF-Abfrage auf die erzeugte SQL-Abfrage von weniger als einer Sekunde reduzierte, bestand darin, das verzögerte Laden zu deaktivieren.

Um diese Einstellung zu finden (ef 6), gehen Sie zur .edmx-Datei und suchen Sie unter Eigenschaften -> Codegenerierung -> Lazy Loading Enabled. Auf false setzen.

Massive Leistungsverbesserung für mich.

Ich hatte auch dieses Problem. Es stellte sich heraus, dass der Schuldige in meinem Fall das Schnüffeln von SQL-Server- Parametern war .

Der erste Hinweis darauf, dass mein Problem tatsächlich auf das Sniffing von Parametern zurückzuführen war, war, dass das Ausführen der Abfrage mit "Arithabort deaktivieren" oder "Arithabort setzen auf" drastisch unterschiedliche Ausführungszeiten in Management Studio ergab. Dies liegt daran, dass ADO.NET standardmäßig "Arithabort deaktivieren" verwendet und Management Studio standardmäßig "Arithabort festlegen" verwendet. Der Abfrageplan-Cache enthält abhängig von diesem Parameter unterschiedliche Pläne.

Ich habe das Zwischenspeichern von Abfrageplänen für die Abfrage deaktiviert. Die Lösung finden Sie hier .