Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:✅ SQL-Analyseendpunkt und Warehouse in Microsoft Fabric
Die Zwischenspeicherung von Ergebnismengen (Vorschau) ist eine integrierte Performanceoptimierung für Fabric Data Warehouse- und Lakehouse SQL-Analyseendpunkte, die die Leselatenz verringert.
Das Zwischenspeichern von Resultsets funktioniert, indem die endgültigen Resultsets für anwendbare SELECT T-SQL-Abfragen gespeichert werden, sodass nachfolgende Ausführungen, die einen Cache-Treffer erzielen, nur das endgültige Resultset verarbeiten. Dies kann komplexe Kompilierung und Datenverarbeitung der ursprünglichen Abfrage umgehen und nachfolgende Abfragen schneller zurückgeben.
Data Warehouse-Szenarien umfassen in der Regel analytische Abfragen, die große Datenmengen verarbeiten, um ein relativ kleines Ergebnis zu erzielen. Beispielsweise kann eine SELECT Abfrage, die mehrere Verknüpfungen enthält, Lese- und Shuffles für Millionen von Datenzeilen ausführt, zu einer Aggregation führen, die nur wenige Zeilen lang ist. Bei Workloads wie Berichten oder Dashboards, die dazu neigen, dieselben analytischen Abfragen wiederholt auszulösen, kann dieselbe schwere Berechnung mehrmals ausgelöst werden, auch wenn das Endergebnis unverändert bleibt. Die Zwischenspeicherung von Ergebnisdatenmengen verbessert die Leistung in diesen und ähnlichen Szenarien bei ungefähr gleichen Kosten.
Von Bedeutung
Dieses Feature befindet sich in der Vorschauphase.
Automatische Verwaltung des Caches
Der Ergebnissatz-Cache funktioniert transparent. Sobald sie aktiviert ist, wird die Cacheerstellung und -wiederverwendung opportunistisch für Abfragen angewendet.
Das Zwischenspeichern von Resultset gilt für SELECT T-SQL-Abfragen in Lagertabellen, Verknüpfungen zu OneLake-Quellen und Verknüpfungen zu Nicht-Azure-Quellen. Die Verwaltung des Caches wird automatisch verarbeitet, wobei der Cache bei Bedarf regelmäßig entfernt wird.
Darüber hinaus wird beim Ändern der Daten die Konsistenz der Ergebnisse sichergestellt, indem der zuvor erstellte Cache ungültig gemacht wird.
Konfigurieren der Zwischenspeicherung von Resultset
Die Zwischenspeicherung des Resultsets kann auf Elementebene konfiguriert werden.
Nach der Aktivierung kann sie bei Bedarf auf Elementebene oder für einzelne Abfragen deaktiviert werden.
Während der Vorschau ist die Zwischenspeicherung des Resultsets für alle Elemente standardmäßig deaktiviert.
Konfiguration auf Elementebene
Verwenden Sie den ALTER DATABASE SET T-SQL-Befehl, um die Zwischenspeicherung von Resultsets für ein Lakehouse oder Data Warehouse zu ermöglichen. Verwenden Sie den SQL-Analyseendpunkt eines Lakehouse zum Verbinden und Ausführen von T-SQL-Abfragen.
ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING ON;
Der Einstellungswert kann in sys.databases eingecheckt werden, um z. B. den Wert für den aktuellen Kontext im Fabric Warehouse- oder Lakehouse SQL-Analyseendpunkt anzuzeigen:
SELECT name, is_result_set_caching_on
FROM sys.databases
WHERE database_id = db_id();
So deaktivieren Sie die Zwischenspeicherung der Ergebnismengen:
ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING OFF;
Konfiguration auf Abfrageebene
Sobald das Zwischenspeichern des Ergebnis-Caches für ein Element aktiviert ist, kann es für eine einzelne Abfrage deaktiviert werden.
Dies kann hilfreich für das Debuggen oder A/B-Testing einer Abfrage sein. Deaktivieren Sie die Zwischenspeicherung von Resultset für eine Abfrage, indem Sie diesen Hinweis am Ende des Folgenden SELECTanfügen:
OPTION ( USE HINT ('DISABLE_RESULT_SET_CACHE') );
Überprüfen der Cachenutzung des Resultsets
Die Cacheverwendung des Resultsets kann an zwei Orten überprüft werden: Nachrichtenausgabe und die queryinsights.exec_requests_history Systemansicht.
In der Nachrichtenausgabe einer Abfrage (sichtbar im Fabric Query-Editor oder SQL Server Management Studio) wird die Anweisung "Resultsetcache wurde verwendet" nach der Abfrageausführung angezeigt, wenn die Abfrage einen vorhandenen Resultsetcache verwenden konnte.
In queryinsights.exec_requests_history zeigt die Spalte result_cache_hit einen Wert an, der die Verwendung des Resultset-Caches für jede Abfrageausführung angibt.
-
2: Die Abfrage hat den Ergebniscache verwendet (Cachetreffer) -
1: Die Abfrage hat den Ergebnismengen-Cache erstellt. -
0: Die Abfrage war nicht geeignet für die Erstellung oder Nutzung des Ergebniszwischenspeichers.
Beispiel:
SELECT result_cache_hit, command, *
FROM queryinsights.exec_requests_history
ORDER BY submit_time DESC;
Qualifizieren für die Zwischenspeicherung von Resultset
Wenn eine SELECT Abfrage ausgegeben wird, wird sie hinsichtlich der Zwischenspeicherung des Resultsets bewertet. Um einen Resultset-Cache erstellen und verwenden zu können, müssen verschiedene Anforderungen erfüllt sein. Einige dieser helfen, den Cachespeicher unter internen Grenzwerten zu halten, einige helfen, das Zwischenspeichern für komplexe Abfragen zu reservieren, und andere helfen, die Ergebnisrichtigkeit bei wiederholten Zugriffen aufrechtzuerhalten. Ein offensichtliches SELECT Beispiel ist das Einschränken von Abfragen, bei GETDATE() denen verhindert wird, dass das Ergebnis zwischengespeichert wird, aber es gibt auch andere differenzierte Fälle, in denen Fabric entscheidet, Ergebnisse nicht zwischenzuspeichern.
Die folgende Liste enthält allgemeine Ausschlussgründe für die Zwischenspeicherung von Ergebnismengen im Fabric Data Warehouse. Wenn Sie feststellen, dass eine Abfrage für das Erstellen des Resultsetcaches nicht anwendbar war, kann dies auf einen oder mehrere der folgenden Gründe zurückzuführen sein:
- Das Zwischenspeichern von Resultset ist für das aktuell verbundene Element nicht aktiviert, oder es ist für das Element aktiviert, aber die Abfrage enthielt den
DISABLE_RESULT_SET_CACHEHinweis. - Abfrage ist keine reine
SELECT, z. B.CREATE TABLE AS SELECT(CTAS),SELECT-INTO, andere Datenänderungssprache. - Abfrage verweist auf ein Systemobjekt, eine temporäre Tabelle, eine Metadatenfunktion oder verweist nicht auf verteilte Objekte.
- Abfrage verweist nicht auf mindestens eine Tabelle mit mindestens 100.000 Zeilen.
- Abfrage verweist auf ein Objekt außerhalb des aktuell verbundenen Fabric-Elements (z. B. datenbankübergreifende Abfrage)
- Abfrage befindet sich in einer expliziten Transaktion oder einer
WHILESchleife. - Die Abfrageausgabe enthält einen nicht unterstützten Datentyp und/oder den
VARCHAR(MAX)Datentyp und/oder denVARBINARY(MAX)Datentyp. Unterstützte Datentypen finden Sie unter Datentypen in Fabric Data Warehouse - Die Abfrage enthält ein
CASToderCONVERT, das sich auf den Datentyp date oder sql_variant bezieht. - Abfrage enthält Laufzeitkonstanten (wie z. B.
CURRENT_USERoderGETDATE()) - Das Abfrageergebnis wird auf 10.000 Zeilen geschätzt > .
- Die Abfrage enthält nicht deterministische integrierte Funktionen, Fensteraggregatfunktionen oder sortierte Funktionen wie
PARTITION BY … ORDER BY. Siehe deterministische und nichtdeterministische Funktionen. - Abfrage verwendet dynamische Datenformatierung, Sicherheit auf Zeilenebene oder andere Sicherheitsfeatures
- Abfrage verwendet Zeitreisen
- Abfrage wendet ORDER BY auf eine Spalte oder einen Ausdruck an, die nicht in der Abfrageausgabe enthalten ist.
- Abfrage befindet sich in einer Sitzung mit Anweisungen auf Sitzungsebene
SETmit nicht standardmäßigen Werten (z. B. EinstellungQUOTED_IDENTIFIERaufOFF) - Das System hat interne Grenzwerte für den Cache erreicht. Hintergrundcache-Eviction-Prozesse geben Speicherplatz frei, bevor ein neuer Cache erstellt wird.
Diese Regeln gelten auch für die erneute Nutzung des Caches bei nachfolgenden Ausführungen derselben Abfrage. Darüber hinaus kann ein Cache in den folgenden Szenarien nicht verwendet werden:
- Alle Änderungen an den tabellen, auf die verwiesen wird, seit der Cache erstellt wurde
- Der Arbeitsbereich ist seit der Erstellung eines Caches nicht mehr verfügbar, ähnlich wie bei im Arbeitsspeicher- und Festplatten-Caching
- Der Benutzer verfügt nicht über ausreichende Berechtigungen für die Objekte in der Abfrage.
- Die Abfrage wird von einer anderen Lakehouse- oder Warehouse-Verbindung aufgerufen als der Ort, an dem die ursprüngliche Abfrage ausgestellt wurde. (Datenbankübergreifende Abfragen sind nicht für die Zwischenspeicherung von Ergebnis-Sets geeignet.)
- Die Abfrage verwendet unterschiedliche Ausgabespalten, Spaltenreihenfolgen oder Aliase als die ursprüngliche Abfrage.
- Die zwischengespeicherte Abfrage wurde in 24 Stunden nicht verwendet.
Hinweis
Da diese Qualifikationen intern zur besten Anwendung der Ergebnissatzzwischenspeicherung bewertet werden, ist es wichtig zu beachten, dass sie in Zukunft aktualisiert werden könnten.