Nach der Profilierung meiner Entity Framework 4.0-basierten Datenbankschicht habe ich festgestellt, dass der Hauptleistungssünder eine einfache LINQ Any () ist, mit der ich überprüfe, ob eine Entität in der Datenbank bereits existiert. Die Überprüfung Any () führt Größenordnungen langsamer aus als das Speichern der Entität. Es gibt relativ wenige Zeilen in der Datenbank und die zu überprüfenden Spalten sind indiziert.
Ich verwende den folgenden LINQ, um nach dem Vorhandensein einer Einstellungsgruppe zu suchen:
%Vor%Dies generiert die folgende SQL (zusätzlich behauptet mein SQL Profiler, dass die Abfrage zweimal ausgeführt wird):
%Vor%Im Moment kann ich nur daran denken, gespeicherte Prozeduren zu erstellen, um dieses Problem zu lösen, aber ich würde es natürlich vorziehen, den Code in LINQ zu behalten.
Gibt es eine Möglichkeit, einen solchen Exist-Check mit EF schneller auszuführen?
Ich sollte wahrscheinlich erwähnen, dass ich auch Self-Tracking-Entities in einer n-Tier-Architektur verwende. In einigen Szenarien wird der ChangeTracker-Status für einige Entitäten auf "Hinzugefügt" gesetzt, obwohl sie bereits in der Datenbank vorhanden sind. Aus diesem Grund verwende ich eine Prüfung, um den ChangeTracker-Status entsprechend zu ändern, wenn das Aktualisieren der Datenbank eine Ausnahme für das Einfügen von Fehlern verursachte.
Das Problem ist, dass Entity Framework (zumindest EF4) dummes SQL erzeugt. Der folgende Code scheint anständiges SQL mit minimalem Schmerz zu erzeugen.
%Vor%Dann können Sie tun:
%Vor%oder sogar:
%Vor%Fügen Sie der Datenbanktabelle "SettingGroups" einen Index nach Group & amp; Kategorie.
BTW, produziert das ähnliche sql?
%Vor%Ich weiß, es klingt eine miserable Lösung, aber was passiert, wenn Sie Count statt Any verwenden?
Haben Sie die Zeit für die Ausführung der generierten Select-Anweisung in Bezug auf die Zeit für die Ausführung der Auswahl profiliert? Wählen Sie aus, was Sie erwarten würden / möchten. Es ist möglich, dass es nicht so schlimm ist, wie es aussieht.
Der Abschnitt
%Vor%liegt wahrscheinlich nahe bei dem, was Sie erwarten würden. Es ist durchaus möglich, dass der Abfrageoptimierer erkennt, dass die zweite Abfrage die gleiche wie die erste Abfrage ist und daher sehr wenig Zeit für die gesamte Abfrage benötigt.
Tags und Links entity-framework linq performance