Power Query Abfragen langsam? Bottlenecks finden mit Query Diagnostics

Wer kennt es nicht: Man baut eine Power Query Abfrage auf, fügt ein paar Schritte hinzu, führt einen Merge durch, filtert ein wenig – und plötzlich dauert das Laden der Daten ewig. Der kleine Ladekreis in Power BI oder Excel dreht sich unaufhörlich, und man fragt sich: Was genau passiert da eigentlich im Hintergrund? Warum ist dieser eine Schritt so viel langsamer als die anderen? In der Vergangenheit war die Performance-Analyse von Power Query oft ein Ratespiel. Man hat Schritte testweise gelöscht, die Reihenfolge geändert oder gehofft, dass Query Folding irgendwie “schon passt”. Doch Microsoft hat mit den Query Diagnostics ein mächtiges Werkzeug-Set direkt in den Power Query Editor integriert, das tiefere Einblicke erlaubt, als es früher möglich war. In diesem ausführlichen Guide tauchen wir tief in die Welt der Performance-Analyse ein. Wir schauen uns an, wie Sie Query Diagnostics aktivieren, die resultierenden Berichte lesen und – was am wichtigsten ist – wie Sie aus diesen Daten die richtigen Schlüsse ziehen, um Ihre Abfragen massiv zu beschleunigen.

Das Problem der “Black Box” Power Query

Power Query ist für viele Anwender eine wunderbare “Black Box”. Man klickt auf Schaltflächen, transformiert Daten, und am Ende kommt eine saubere Tabelle heraus. Solange die Datenmengen klein sind, ist das alles kein Problem. Doch sobald wir über Millionen von Zeilen sprechen oder komplexe APIs und SQL-Server anbinden, wird Effizienz zur Überlebensfrage für Ihre Berichte.

Das Hauptproblem ist, dass Power Query versucht, extrem “smart” zu sein. Die Mashup-Engine optimiert im Hintergrund, wertet Dinge parallel aus und versucht, so viel Arbeit wie möglich an die Datenquelle zurückzugeben (Query Folding). Wenn diese Automatismen jedoch scheitern – etwa weil wir eine Transformation nutzen, die die Quelle nicht versteht – fällt Power Query in den “Local Processing”-Modus zurück. Das bedeutet: Alle Daten werden roh über das Netzwerk geladen und mühsam im RAM Ihres Rechners verarbeitet. Ohne Query Diagnostics sehen Sie nur das Ergebnis: Es dauert lange. Mit Query Diagnostics sehen Sie den Grund: “Aha, hier wurde das Folding unterbrochen, und nun lädt Power Query 10 GB Daten lokal.”

🚀 Profi-Tipp für den Start: Bevor Sie tief in die Diagnose einsteigen, sollten Sie sicherstellen, dass Sie die Grundlagen der Engine verstanden haben. Ein solides Verständnis für Power Query Tricks zur Performance-Optimierung hilft Ihnen dabei, die Diagnose-Ergebnisse schneller einzuordnen und typische Anfängerfehler direkt zu vermeiden.

Query Diagnostics aktivieren: So schauen Sie unter die Haube

Um die Diagnose zu nutzen, müssen Sie im Power Query Editor (egal ob in Power BI Desktop oder Excel) zum Reiter Tools navigieren. Dort finden Sie die Gruppe “Query Diagnostics”.

Die verschiedenen Diagnose-Modi

1. Start Diagnostics: Dies ist der manuelle Modus. Sie klicken auf Start, führen dann die Aktion aus, die langsam ist (z.B. eine Vorschau aktualisieren), und klicken auf Stop.
2. Diagnose Step: Wenn Sie wissen möchten, wie lange ein ganz spezieller Schritt in Ihrer Liste der “Angewendeten Schritte” dauert, können Sie diesen markieren und “Diagnose Step” wählen.
3. Session Diagnostics: Zeichnet die gesamte Sitzung auf, was oft zu viele Daten liefert, aber gut für eine globale Übersicht ist.

Wichtiger Hinweis zu Admin-Rechten: Früher benötigte Query Diagnostics oft administrative Rechte auf dem Windows-Rechner, da System-Traces geschrieben wurden. In den aktuellen Versionen von Power BI Desktop können Sie dies in den Optionen unter “Diagnostics” umstellen, sodass die Traces auch ohne Admin-Rechte im Rahmen der aktuellen Sitzung erstellt werden können. Sollten Sie die Schaltflächen also ausgegraut sehen, prüfen Sie Ihre Berechtigungen oder die globalen Einstellungen.

📖 Weiterführende Informationen: Für technische Details zu allen verfügbaren Spalten, Diagnose-Modi und erweiterte Analyse-Techniken finden Sie in der offiziellen Microsoft-Dokumentation zu Query Diagnostics eine umfassende Referenz.

Die Diagnose-Ergebnisse verstehen: Die zwei magischen Tabellen

Sobald Sie die Diagnose beenden, generiert Power Query automatisch eine neue Gruppe von Abfragen in Ihrem Editor. Diese Tabellen enthalten die Rohdaten Ihrer Analyse. Erschrecken Sie nicht: Das sieht im ersten Moment nach sehr viel technischem Kauderwelsch aus, aber wir konzentrieren uns auf die Spalten, die wirklich zählen.

1. Die Tabelle “Detailed Traces”

Dies ist das detaillierteste Protokoll – hier wird jede einzelne Bewegung der Mashup-Engine aufgezeichnet. Jede Datenquellenanfrage, jede interne Transformation und jede Metadaten-Abfrage erscheint als eigene Zeile. Auf den ersten Blick wirkt diese Tabelle erschlagend, aber sie enthält die wertvollsten Hinweise für echte Performance-Analysen.

Die wichtigsten Spalten im Überblick:

Identifikation & Navigation:

• Query: Welche Ihrer Abfragen gerade aktiv war
• Step: Der konkrete Schritt aus Ihrer “Angewendete Schritte”-Liste
• Id: Eindeutige Kennung der Auswertung (wichtig zum Filtern)

Performance-Analyse:

• Exclusive Duration: Die Millisekunden, die eine Operation tatsächlich aktiv war (ohne Wartezeiten). Sortieren Sie nach dieser Spalte absteigend – so finden Sie sofort die größten Zeitfresser.
• Start Time / End Time: Wann eine Operation begonnen und geendet hat

Das Game-Changer-Feature für SQL-Nutzer:

• Data Source Queries:
  Diese Spalte ist Gold wert! Hier sehen Sie die exakten SQL-Statements (oder API-Calls), die Power Query an Ihre Datenquelle sendet.
  ✅ Gutes Zeichen: Sie sehen ein komplexes SQL-Statement mit JOINs, WHERE-Clauses und GROUP BY → Query Folding funktioniert perfekt.
  ⚠️ Warnsignal: Die Spalte ist leer oder zeigt nur einfache SELECT-Statements → Power Query lädt große Datenmengen lokal und verarbeitet sie im RAM Ihres Rechners.

Praxis-Tipp: Filtern Sie die Tabelle zunächst nach einer konkreten Auswertung (über die Id-Spalte), dann nach Ihrer Ziel-Query. So reduzieren Sie die Datenmenge auf das Wesentliche und finden schneller die relevanten Bottlenecks.

2. Die Tabelle “Aggregated Traces”

Diese Tabelle ist für schnelle Performance-Checks oft wertvoller als die Detailed-Version. Während “Detailed Traces” jede einzelne Mikro-Operation zeigt, fasst “Aggregated Traces” verwandte Operationen zu größeren Blöcken zusammen und summiert deren Laufzeiten.

Was Sie hier sehen:
Die Tabelle gruppiert Operationen nach Query und Step und zeigt Ihnen die Gesamtdauer pro Schritt. So erkennen Sie auf einen Blick: “Der Schritt ‘Zusammengeführte Abfragen’ hat 45 Sekunden gedauert, während alle anderen Schritte nur wenige Millisekunden brauchten.”

Wann welche Tabelle nutzen?

• Aggregated Traces: Für den schnellen Überblick → “Welcher Schritt ist langsam?”
• Detailed Traces: Für die Tiefenanalyse → “WARUM ist dieser Schritt langsam?”

Die meisten Analysen starten in Aggregated Traces, und nur bei komplexen Problemen wechselt man zur Detailed-Ansicht.

⚙️ Systematisch vorgehen: Oft sind Performance-Probleme nur ein Symptom tieferliegender Konfigurationsfehler. Falls Ihre Diagnose zeigt, dass zwar die Daten schnell kommen, aber die Logik instabil ist, hilft oft ein systematischer Blick auf die Fehlerbehebung in Power BI, um etwaige Konflikte mit Datenschutzebenen oder veralteten Treibern auszuschließen.

Den Flaschenhals identifizieren: Eine Schritt-für-Schritt-Analyse

Nehmen wir an, Sie haben eine Abfrage, die zwei SQL-Tabellen verknüpft und dann nach einem Datum filtert. In der Diagnose sehen Sie nun, dass der Merge-Schritt extrem lange dauert.

Fall A: Query Folding wird unterbrochen

In der Spalte Data Source Queries sehen Sie zwei separate Abfragen für Tabelle 1 und Tabelle 2, aber keinen kombinierten Join. Das bedeutet, Power Query lädt beide Tabellen komplett in den Arbeitsspeicher Ihres PCs und führt den Join lokal aus. Bei zwei Tabellen mit je 1 Million Zeilen ist das der Performance-Tod.
Lösung: Prüfen Sie, ob Sie Transformationen vor dem Merge nutzen, die das Folding unterbrechen (z.B. Datentyp-Änderungen, die der SQL-Server nicht eins-zu-eins versteht). Versuchen Sie, den Filter vor den Merge zu ziehen.

Fall B: Die Datenquelle ist der Flaschenhals

Sie sehen in der Diagnose, dass eine “Data Source Query” 60 Sekunden dauert. Power Query wartet also schlichtweg auf den SQL-Server.
Lösung: Hier kann Power Query wenig tun. Sie müssen Ihre Datenbank-Indizes prüfen oder das SQL-Statement optimieren (vielleicht durch eine View auf dem Server).

Fall C: Konstante Metadaten-Abfragen

Manchmal sehen Sie hunderte kleine Einträge in der “Detailed Traces”-Tabelle mit einer Dauer von wenigen Millisekunden. Das passiert oft bei Cloud-Quellen oder Excel-Dateien auf SharePoint. Power Query fragt immer wieder “Ist die Datei noch da? Wie sehen die Spalten aus?”.
Lösung: Hier kann es helfen, die Daten einmal zentral aufzubereiten und nicht in jedem einzelnen Bericht direkt auf die Quelldateien zuzugreifen.

📊 Zentrale Architektur: Wenn Sie merken, dass dieselben langsamen Transformationen in fünf verschiedenen Berichten auftauchen, ist es Zeit für einen Architekturwechsel. Mit Power BI Dataflows als zentralem ETL-Fundament führen Sie die rechenintensive Diagnose und Optimierung nur einmal durch und verteilen die sauberen Daten performant an alle Berichte.

Fortgeschrittene Techniken: Privacy Levels und die “Formula Firewall”

Ein oft übersehener Aspekt in den Query Diagnostics sind Verzögerungen durch die “Formula Firewall”. Power Query schützt Ihre Daten, indem es verhindert, dass Daten aus einer “privaten” Quelle (z.B. eine lokale Excel-Liste) ungefragt an eine “öffentliche” Quelle (z.B. eine SQL-Datenbank) gesendet werden.

In der Diagnose äußert sich dies oft durch Schritte namens “Remote Query” oder “Waiting for other queries”. Wenn die Mashup-Engine nicht sicher ist, ob sie einen Filter (aus der Excel-Liste) direkt in das SQL-Statement (für die Datenbank) schreiben darf, wird sie es sicherheitshalber lokal machen.
Das Deaktivieren der Privacy-Checks (nur in vertrauenswürdigen Umgebungen!) kann in der Diagnose oft wie ein “Turbo-Knopf” wirken. Plötzlich sehen Sie in der Data Source Queries-Tabelle ein optimiertes Statement, das vorher nicht da war.

Fazit: Daten statt Raten

Query Diagnostics macht Schluss mit dem “Stochern im Nebel”. Statt blind Schritte zu löschen oder Foren nach Tipps zu durchsuchen, die vielleicht gar nicht auf Ihr spezifisches Problem passen, geben Ihnen die Diagnostics-Tabellen eine exakte Roadmap für die Optimierung.

Die wichtigste Erkenntnis aus fast jeder Diagnose-Sitzung ist: Query Folding ist der Königsweg. Wenn Sie sehen, dass die Engine lokal arbeitet (“Local Engine” Einträge in den Traces), ist das fast immer Ihr größter Hebel. Versuchen Sie, die Schritte so anzuordnen, dass die Spalte “Exclusive Duration” für lokale Operationen gegen Null geht.

Die Arbeit mit Query Diagnostics erfordert am Anfang etwas Geduld, um die Tabellen lesen zu lernen. Aber sobald Sie den ersten “Aha-Moment” hatten, weil Sie einen 30-minütigen Ladevorgang durch das Umstellen von zwei Schritten auf 10 Sekunden reduziert haben, werden Sie dieses Tool nie wieder missen wollen. Nutzen Sie die Transparenz, die Microsoft uns hier bietet, und machen Sie Ihre Power BI Berichte und Excel-Tools zu dem, was sie sein sollten: Schnell, effizient und professionell.

✅ Getestet mit Power BI Desktop Version Dezember 2025.

Ihre Erfahrungen sind gefragt!

Wie läuft die Zusammenarbeit mit Power Query Diagnostics? Haben Sie Performance-Engpässe schon erfolgreich in Ihren Workflow integriert, oder kämpfen Sie noch mit langsamen Ladezeiten? In meinen weiteren Power Query Artikeln finden Sie mehr Praxis-Tipps und Tricks für den Arbeitsalltag.