Analyse von EF Core SQL-Abfragen

Warum EF-Core-Abfragen oft eine Blackbox bleiben

Entity Framework nimmt einen Großteil der Datenzugriffslogik ab. Aus wenigen Zeilen LINQ wird fertiges SQL generiert, ohne dass Entwicklerinnen und Entwickler eine eigene Anweisung schreiben müssen. Diese Bequemlichkeit hat jedoch ihren Preis: Zwischen dem DbContext und der Datenbank sitzt eine Übersetzungsschicht, und was dabei am Ende tatsächlich an SQL entsteht, bleibt im Entwicklungsalltag häufig verborgen. Was nicht sichtbar ist, lässt sich jedoch auch nur schwer optimieren. Genau dort entstehen die typischen Performance-Fallen: das berüchtigte N+1-Problem, unnötig aufgeblähte Ergebnismengen oder fehlende Indizes.

An dieser Stelle kommt das SQL Server Management Studio (SSMS) ins Spiel. Damit lässt sich ein Blick in diese Blackbox werfen, um nicht nur zu sehen, was die Datenbank tatsächlich tut, sondern vor allem zu verstehen, warum eine Abfrage langsam ist und wie sie sich optimieren lässt.

EF-Core-Abfragen mit SSMS sichtbar machen

Generierte SQL-Abfragen im SSMS auffinden

Der Vorteil dieses Ansatzes: Am Anwendungscode muss nichts geändert werden. Alle Abfragen, die EF gegen die Datenbank schickt, lassen sich mit Funktionen von SSMS ermitteln. Am bequemsten gelingt dies über den Abfragespeicher (Query Store). Einmal pro Datenbank aktiviert (Datenbank → Eigenschaften → „Abfragespeicher", Betriebsmodus „Lesen/Schreiben"), zeichnet er ab sofort automatisch jede ausgeführte Abfrage samt Ausführungsplan und Laufzeitstatistik auf, ganz ohne einen Handgriff im Quellcode.

Unter der Datenbank taucht dann der Ordner „Abfragespeicher" auf, mit fertigen Ansichten wie „Top-Ressourcen verbrauchende Abfragen". Die von EF generierten Statements erkennt man dort meist auf den ersten Blick: eckige Klammern um jede Spalte, Tabellenaliase wie [o] und Parameternamen mit dem typischen doppelten Unterstrich, etwa @__customerId_0.

‍

‍

Wer lieber live mitlesen möchte, greift zu den Erweiterten Ereignissen (Extended Events) unter „Verwaltung". Für einen schnellen Überblick reicht aber auch oft schon der Aktivitätsmonitor (Rechtsklick auf die Serverinstanz): Im Bereich „Aktuelle ressourcenintensive Abfragen" stehen die teuersten Statements der letzten Zeit. Unabhängig davon, welcher der drei Wege gewählt wird, steht am Ende immer dieselbe Frage: Warum ist die Abfrage eigentlich langsam?

Wo geht die Zeit verloren?

Aus dem Abfragespeicher lässt sich der gespeicherte Ausführungsplan mit einem Klick öffnen, die Abfrage muss dafür nicht noch einmal laufen. Der Plan zeigt als Baum, wie der Server die Abfrage abarbeitet: gelesen wird von rechts nach links. Jeder Operator trägt einen Kostenanteil in Prozent, und genau die teuren Knoten sind die Stellen, an denen sich ein genauerer Blick lohnt. Typische Verdächtige sind Table Scan, Index Scan und, wie im folgenden Beispiel, der Key Lookup, der für jede Zeile einzeln in die Tabelle zurückspringt.

Fehlende Indizes erkennen

Erkennt der Optimizer, dass ein passender Index die Abfrage beschleunigen würde, blendet SSMS oberhalb des Plans einen grünen Hinweis mit einem fertigen CREATE INDEX-Vorschlag ein. Das ist ein guter Startpunkt, aber kein Automatismus: Jeder zusätzliche Index kostet Speicher und bremst Schreibvorgänge. Der Vorschlag muss deshalb geprüft werden und darf nicht ungeprüft übernommen werden.

Die Wirkung messbar machen

Ob eine Optimierung wirklich etwas bringt, zeigt sich erst im Vergleich zwischen vorher und nachher. Mit SET STATISTICS IO, TIME ON liefert der Server im Reiter „Meldungen" konkrete Zahlen: logische Lesevorgänge sowie CPU-Zeit und Dauer. Erst wenn diese Werte nach der Änderung spürbar niedriger ausfallen, hat sich die Optimierung tatsächlich gelohnt.

Fazit: Sichtbarkeit als Grundlage für performante EF-Abfragen

In der Praxis dauert es oft eine ganze Weile, bis dieser Zusammenhang bewusst wird. Ein blindes Verlassen auf EF, ohne sich mit dem darunterliegenden SQL zu beschäftigen, ist dabei keine Seltenheit. Erst die intensivere Beschäftigung mit Analyse und Auswertung von Queries schafft hier Abhilfe, und genau dabei soll dieser Artikel unterstützen: die von EF generierten Abfragen zunächst sichtbar zu machen. Denn nur was sichtbar ist, lässt sich auch gezielt verbessern. Diese Herangehensweise hat einen angenehmen Nebeneffekt: EF-Abfragen werden von Anfang an bewusster und sauberer geschrieben, statt Performance-Probleme erst im Nachhinein auszubügeln.

‍