Kardinalitätsschätzung (SQL Server)

Gilt für:SQL ServerAzure SQL-DatenbankVerwaltete Azure SQL-InstanzSQL-Datenbank in Microsoft Fabric

Der Abfrageoptimierer von SQL Server arbeitet kostenorientiert. Das bedeutet, dass er die Abfragepläne zur Ausführung auswählt, die die niedrigsten geschätzten Verarbeitungskosten aufweisen. Der Abfrageoptimierer bestimmt die Kosten für die Ausführung eines Abfrageplans anhand zweier Hauptfaktoren:

• Die Gesamtanzahl der Zeilen, die auf den jeweiligen Stufen eines Abfrageplans verarbeitet werden. Wird als Kardinalität des Plans bezeichnet.
• Das Kostenmodell des Algorithmus, der von den in der Abfrage verwendeten Operatoren vorgeschrieben wird.

Der erste Faktor, die Kardinalität, wird als Eingabeparameter für den zweiten Faktor, das Kostenmodell, verwendet. Aus diesem Grund führt eine verbesserte Kardinalität zu verbesserten geschätzten Kosten und wiederum zu schnelleren Ausführungsplänen.

Die Kardinalitätsschätzung (CE) in SQL Server wird hauptsächlich aus Histogrammen abgeleitet, die beim Erstellen von Indizes oder Statistiken erzeugt werden, entweder manuell oder automatisch. In manchen Fällen verwendet SQL Server auch Einschränkungsinformationen und logische Umschreibungen von Abfragen, um die Kardinalität zu bestimmen.

In den folgenden Fällen kann SQL Server die Kardinalitätswerte nicht genau berechnen. Dies führt zu ungenauen Kostenberechnungen, die wiederum nicht optimale Abfragepläne zur Folge haben können. Die Vermeidung dieser Konstrukte in Abfragen könnte die Abfrageleistung verbessern. In manchen Fällen sind alternative Abfrageformulierungen oder andere Maßnahmen möglich, die nachstehend angegeben sind:

• Abfragen mit Prädikaten, die Vergleichsoperatoren zwischen verschiedenen Spalten derselben Tabelle verwenden.
• Abfragen mit Prädikaten, die Operatoren verwenden, und für die eine der folgenden Voraussetzungen zutrifft:
  • Es liegen keine Statistiken zu den beteiligten Spalten auf beiden Seiten der Operatoren vor.
  • Die Verteilung der Werte in den Statistiken ist nicht einheitlich, die Abfrage sucht jedoch einen sehr selektiven Satz an Werten. Dieser Umstand tritt besonders dann ein, wenn ein anderer Operator als der equality-Operator (=) verwendet wird.
  • Das Prädikat verwendet den Ungleich-Vergleichsoperator (!=) oder den logischen Operator NOT.
• Abfragen, die eine der integrierten SQL Server-Funktionen oder eine benutzerdefinierte Skalarwertfunktion verwenden, deren Argument kein konstanter Wert ist.
• Abfragen, bei denen Spalten durch arithmetische Operatoren oder Zeichenfolgenverkettungsoperatoren verknüpft werden.
• Abfragen, die Variablen vergleichen, deren Werte zum Zeitpunkt der Kompilierung und Optimierung nicht bekannt sind.

In diesem Artikel wird erläutert, wie Sie die für Ihr System beste CE-Konfiguration bewerten und auswählen können. Die meisten Systeme profitieren von der neuesten CE, da sie die genaueste ist. Die CE schätzt, wie viele Zeilen Ihre Abfrage wahrscheinlich zurückgibt. Die Vorhersage der Kardinalität wird vom Abfrageoptimierer verwendet, um einen optimalen Abfrageplan zu generieren. Mit genaueren Schätzungen kann der Abfrageoptimierer in der Regel einen besseren Abfrageplan erzeugen.

Möglicherweise existiert in Ihrem Anwendungssystem eine wichtige Abfrage, deren Plan aufgrund von Änderungen an der Kardinalitätsschätzung zwischen Versionen in einen langsameren Plan geändert wird. Sie verfügen über Techniken und Werkzeuge, um eine Abfrage zu identifizieren, die aufgrund von Problemen mit der Kardinalitätsschätzung langsamer ausgeführt wird. Darüber hinaus verfügen Sie über Optionen, wie Sie das daraus resultierende Leistungsproblem beheben.

CE-Versionen

1998 war ein wichtiges Update der CE Teil von SQL Server 7.0, dessen Kompatibilitätsgrad 70 war. Diese Version des CE-Modells basiert auf vier grundlegenden Annahmen:

• Unabhängigkeit: Es wird angenommen, dass Datenverteilungen in verschiedenen Spalten unabhängig voneinander sind, es sei denn, Korrelationsinformationen sind verfügbar und verwendbar.

• Gleichmäßigkeit: Eindeutige Werte sind gleichmäßig verteilt und haben alle dieselbe Häufigkeit. Genauer gesagt sind innerhalb jedes Histogramm-Schritts die eindeutigen Werte gleichmäßig verteilt, und jeder Wert tritt mit derselben Häufigkeit auf.

• Enthaltensein (einfach): Benutzer fragen vorhandene Daten ab. Beispielsweise sollten Sie bei einem Gleichheits-Join zwischen zwei Tabellen in jedem Eingabehistogramm die Prädikatselektivität¹ berücksichtigen, bevor Sie die Histogramme zusammenführen, um die Joinselektivität zu schätzen.

• Einschluss: Bei Filterprädikaten, bei denen Column = Constant gilt, wird angenommen, dass die Konstante für die zugeordnete Spalte tatsächlich existiert. Wenn ein entsprechender Histogrammschritt nicht leer ist, wird angenommen, dass einer der eindeutigen Werte des Schritts mit dem Wert aus dem Prädikat übereinstimmt.

  ¹ Zeilenanzahl, die dem Prädikat entspricht

Spätere Updates beginnen mit SQL Server 2014 (12.x), also mit Kompatibilitätsgrad 120 und höher. Die CE-Updates für Kompatibilitätsgrade 120 und höher enthalten aktualisierte Annahmen und Algorithmen, die bei modernen Data-Warehousing- und OLTP-Workloads gut funktionieren. Von den Annahmen für CE 70 ausgehend wurden ab CE 120 die folgenden Modellannahmen geändert:

• Unabhängigkeit wird zu Korrelation: Die Kombination der verschiedenen Spaltenwerte ist nicht unbedingt unabhängig. Dies ähnelt eher einer realistischen Datenabfrage.
• Einfache Eingrenzung wird zu Basis-Eingrenzung: Benutzer könnten Daten abfragen, die es nicht gibt. Beispielsweise nutzen wir bei einem Gleichheits-Join zwischen zwei Tabellen die Basistabellenhistogramme, um die Joinselektivität zu schätzen, und beziehen anschließend die Selektivität der Prädikate mit ein.

Verwenden des Abfragespeichers zum Bewerten der Version der Kardinalitätsschätzung

Ab SQL Server 2016 (13.x) ist der Abfragespeicher als nützliches Tool enthalten, um die Leistung Ihrer Abfragen zu untersuchen. Sobald der Abfragespeicher aktiviert wird, verfolgt er die Abfrageleistung im Zeitverlauf nach (selbst bei einer Änderung der Ausführungspläne). Überwachen Sie den Abfragespeicher, um eine kostenintensive oder nachlassende Abfrageleistung zu ermitteln. Weitere Informationen finden Sie unter Überwachen der Leistung mithilfe des Abfragespeichers.

Wenn Sie sich auf ein Upgrade auf SQL Server vorbereiten oder eine Datenbankkompatibilitätsstufe auf einer beliebigen SQL Server-Plattform bewerben, sollten Sie die Upgradedatenbanken mithilfe des Abfrageoptimierungs-Assistenten in Betracht ziehen, wodurch die Abfrageleistung in zwei verschiedenen Kompatibilitätsstufen verglichen werden kann.

Verwenden erweiterter Ereignisse zum Bewerten der Version der Kardinalitätsschätzung

Eine weitere Option zur Nachverfolgung des Prozesses der Kardinalitätsschätzung besteht darin, das erweiterte Ereignis query_optimizer_estimate_cardinality zu verwenden. Das folgende Transact-SQL-Codebeispiel wird in SQL Server ausgeführt. Es schreibt eine .xel-Datei nach C:\Temp\ (Sie können den Pfad jedoch ändern). Wenn Sie die XEL-Datei in Management Studio öffnen, werden die detaillierten Daten in einer von Benutzern gut lesbaren Weise angezeigt.

DROP EVENT SESSION Test_the_CE_qoec_1 ON SERVER;
go

CREATE EVENT SESSION Test_the_CE_qoec_1
ON SERVER
ADD EVENT sqlserver.query_optimizer_estimate_cardinality
 (
 ACTION (sqlserver.sql_text)
  WHERE (
  sql_text LIKE '%yourTable%'
  and sql_text LIKE '%SUM(%'
  )
 )
ADD TARGET package0.asynchronous_file_target
 (SET
  filename = 'c:\temp\xe_qoec_1.xel',
  metadatafile = 'c:\temp\xe_qoec_1.xem'
 );
GO

ALTER EVENT SESSION Test_the_CE_qoec_1
ON SERVER
STATE = START;  --STOP;
GO

Informationen zu erweiterten Ereignissen, die speziell auf die SQL-Datenbank zugeschnitten sind, finden Sie unter Erweiterte Ereignisse in SQL-Datenbank.

Schritte zur Bewertung der CE-Version

Im Folgenden finden Sie Schritte, mit denen Sie beurteilen können, ob eine Ihrer wichtigsten Abfragen unter der neuesten CE eine schlechtere Leistung aufweist. In einigen der Schritte wird ein Codebeispiel ausgeführt, das im vorherigen Abschnitt vorgestellt wurde.

1. Öffnen Sie SQL Server Management Studio (SSMS). Stellen Sie sicher, dass für Ihre SQL Server-Datenbank der höchste verfügbare Kompatibilitätsgrad festgelegt wurde.

2. Führen Sie die folgenden vorbereitenden Schritte aus:

   1. Öffnen Sie SQL Server Management Studio (SSMS).

   2. Führen Sie die Transact-SQL-Anweisung aus, um sicherzustellen, dass für Ihre SQL Server-Datenbank der höchste verfügbare Kompatibilitätsgrad festgelegt wurde.

   3. Stellen Sie sicher, dass bei Ihrer Datenbank die LEGACY_CARDINALITY_ESTIMATION Konfiguration OFF aktiviert ist.

   4. Leeren Sie Ihren Abfragespeicher. Stellen Sie sicher, dass für Ihre Datenbank Abfragespeicher AKTIVIERT ist.

   5. Führen Sie die Anweisung SET NOCOUNT OFF; aus.

3. Führen Sie die Anweisung SET STATISTICS XML ON; aus.

4. Führen Sie Ihre wichtige Abfrage aus.

5. Beachten Sie im Ergebnisbereich auf der Registerkarte Meldungen die tatsächliche Anzahl von betroffenen Zeilen.

6. Doppelklicken Sie im Ergebnisbereich auf der Registerkarte Ergebnisse auf die Zelle, die die Statistik im XML-Format enthält. Es wird ein grafischer Abfrageplan angezeigt.

7. Klicken Sie mit der rechten Maustaste auf das erste Feld im grafischen Abfrageplan, und wählen Sie Eigenschaften aus.

8. Notieren Sie die Werte für die folgenden Eigenschaften, um diese später mit einer anderen Konfiguration vergleichen zu können:

   • CardinalityEstimationModelVersion.

   • Geschätzte Anzahl von Zeilen.

   • Geschätzte E/A-Kostensowie einige weitere ähnliche geschätzte Eigenschaften, die sich eher auf die tatsächliche Leistung als auf Vorhersagen zur Zeilenanzahl beziehen.

   • Logische Operation und Physische Operation. Parallelität ist ein guter Wert.

   • Tatsächlicher Ausführungsmodus. Batch ist eine gute Wahl, besser als Row.

9. Vergleichen Sie die geschätzte Anzahl von Zeilen mit der tatsächliche Zeilenanzahl. Liegt die CE um 1 % daneben (zu hoch oder zu niedrig) oder um 10 %?

10. Führen Sie SET STATISTICS XML OFF; aus.

11. Führen Sie die Transact-SQL-Anweisung aus, um den Kompatibilitätsgrad Ihrer Datenbank um eine Stufe zu senken (z. B. von 130 auf 120).

12. Führen Sie alle Schritte erneut aus, die keine Vorbereitungsschritte sind.

13. Vergleichen Sie die CE-Eigenschaftswerte aus den beiden Ausführungen.

    • Ist der Ungenauigkeitsprozentsatz bei der neuesten CE geringer als bei der älteren CE?

14. Vergleichen Sie abschließend die verschiedenen Werte der Leistungseigenschaften aus den beiden Läufen.

    • Wurde für Ihre Abfrage unter den zwei unterschiedlichen Kardinalitätsschätzungen ein anderer Abfrageplan verwendet?

    • Wurde Ihre Abfrage unter der aktuellsten Kardinalitätsschätzung langsamer ausgeführt?

    • Wenn Ihre Abfrage nicht mit der älteren Kardinalitätsschätzung besser und unter einem anderen Plan ausgeführt wird als mit der neuen Schätzung, sollten Sie mit größter Wahrscheinlichkeit die neueste Kardinalitätsschätzung verwenden.

    • Wenn Ihre Abfrage allerdings unter dem älteren CE mit einem schnelleren Ausführungsplan ausgeführt wird, sollten Sie in Erwägung ziehen, das System zu zwingen, den schnelleren Ausführungsplan zu verwenden und den CE zu ignorieren. Auf diese Weise können Sie die neueste CE für alles aktiviert haben und im einen Sonderfall dennoch den schnelleren Plan beibehalten.

So aktivieren Sie den besten Abfrageplan

Angenommen, dass mit CE 120 oder höher ein weniger effizienter Abfrageplan für Ihre Abfrage generiert wird. Nachfolgend sind einige Optionen aufgeführt, um den besseren Plan zu aktivieren (vom größten bis zum kleinsten Bereich):

• Sie können den Kompatibilitätsgrad für Ihre gesamte Datenbank auf einen niedrigeren Wert als den neuesten verfügbaren Grad festlegen.

  • Wenn Sie z.B. den Kompatibilitätsgrad auf 110 oder niedriger festlegen, wird die Kardinalitätsschätzung 70 aktiviert, obwohl alle Abfragen dem vorherigen Kardinalitätsschätzungsmodell unterliegen.

  • Beim Festlegen eines niedrigeren Kompatibilitätsgrads werden außerdem viele Verbesserungen des Abfrageoptimierers für die neuesten Versionen nicht genutzt. Zudem wirkt sich diese Änderung auf alle Abfragen aus, die an die Datenbank gesendet werden.

• Sie können die datenbankbezogene Konfigurationsoption LEGACY_CARDINALITY_ESTIMATION verwenden, um zu erreichen, dass die gesamte Datenbank die ältere Version des Kardinalitätsschätzers verwendet, während andere Verbesserungen im Abfrageoptimierer beibehalten werden.

• Sie können den Abfragehinweis LEGACY_CARDINALITY_ESTIMATION verwenden, sodass eine einzelne Abfrage die ältere Kardinalitätsschätzung verwendet, die Verbesserungen des Abfrageoptimierers jedoch beibehalten werden.

• Sie können die LEGACY_CARDINALITY_ESTIMATION über die Abfragespeicher-Hinweisfunktion erzwingen, um für eine einzelne Abfrage die ältere Kardinalitätsschätzung zu verwenden, ohne die Abfrage selbst zu ändern.

• Erzwingen Sie einen anderen Plan mit Abfragespeicher.

Kompatibilitätsgrad der Datenbank

Sie können sicherstellen, dass ihre Datenbank auf einer bestimmten Ebene ist, indem Sie den folgenden Transact-SQL Code für ALTER DATABASE (Transact-SQL) Kompatibilitätsebene verwenden.

SELECT ServerProperty('ProductVersion');
GO

SELECT d.name, d.compatibility_level
FROM sys.databases AS d
WHERE d.name = 'yourDatabase';
GO

Für bereits vorhandene Datenbanken, die auf niedrigeren Kompatibilitätsebenen ausgeführt werden, ist es ein gültiger Ansatz, um die vorherige Datenbankkompatibilitätsstufe beizubehalten, solange die Anwendung keine Verbesserungen verwenden muss, die nur auf einer höheren Datenbankkompatibilitätsebene verfügbar sind. Für neue Entwicklungsarbeit oder wenn eine vorhandene Anwendung neue Features wie intelligente Abfrageverarbeitung in SQL-Datenbanken sowie einige neue Transact-SQL erfordert, planen Sie, die Datenbankkompatibilitätsstufe auf die neueste verfügbare Version zu aktualisieren. Weitere Informationen finden Sie unter Kompatibilitätsgrade und Upgrades der Datenbank-Engine.

ALTER DATABASE <yourDatabase>
SET COMPATIBILITY_LEVEL = 150;
GO

Für eine SQL Server-Datenbank, die auf Kompatibilitätsgrad 120 oder höher festgelegt ist, erzwingt die Aktivierung des Traceflags 9481, dass das System CE-Version 70 verwendet.

Legacy-Kardinalitätsschätzung

Für eine SQL Server-Datenbank, die auf die Kompatibilitätsebene 120 oder höher festgelegt ist, kann der Legacy-Kardinalitätsschätzer (CE-Version 70) auf Datenbankebene durch Verwenden von ALTER DATABASE SCOPED CONFIGURATION aktiviert werden.

ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
GO

SELECT name, value
FROM sys.database_scoped_configurations
WHERE name = 'LEGACY_CARDINALITY_ESTIMATION';
GO

Abfrage so ändern, dass sie einen Hint verwendet

Ab SQL Server 2016 (13.x) SP1 ändern Sie die Abfrage so, dass der AbfragehinweisUSE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION') verwendet wird.

SELECT CustomerId, OrderAddedDate
FROM OrderTable
WHERE OrderAddedDate >= '2016-05-01'
OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'));

Legen Sie einen Abfragespeicher-Hinweis fest.

Abfragen können dazu gezwungen werden, den alten Kardinalitätsschätzer zu verwenden, ohne die Abfrage zu ändern, und zwar mithilfe von Abfragespeicher-Hinweisen.

1. Identifizieren Sie die Abfrage in den Abfragespeicher-Katalogsichten sys.query_store_query_text und sys.query_store_query. Suchen Sie z. B. mithilfe eines Textfragments nach einer ausgeführten Abfrage:

   SELECT q.query_id, qt.query_sql_text
   FROM sys.query_store_query_text qt
   INNER JOIN sys.query_store_query q ON
   qt.query_text_id = q.query_text_id
   WHERE query_sql_text like N'%ORDER BY ListingPrice DESC%'
   AND query_sql_text not like N'%query_store%';
   

2. Im folgenden Beispiel wird ein Abfragespeicher-Hinweis verwendet, um den Legacy-Kardinalitätsschätzer für query_id 39 zu erzwingen, ohne die Abfrage zu ändern:

   EXEC sys.sp_query_store_set_hints @query_id= 39, @query_hints = N'OPTION(USE HINT(''FORCE_LEGACY_CARDINALITY_ESTIMATION''))';
   

So erzwingen Sie einen bestimmten Abfrageplan

Für die feinste Kontrolle könnten Sie das System zwingen, den Plan zu verwenden, der während Ihrer Tests mit CE 70 generiert wurde. Nachdem Sie Ihren bevorzugten Plan angeheftet haben, können Sie Ihre gesamte Datenbank so einrichten, dass sie den neuesten Kompatibilitätsgrad und CE verwendet. Diese Option wird im nächsten Abschnitt erläutert.

Der Abfragespeicher bietet verschiedene Möglichkeiten, um die Verwendung eines bestimmten Abfrageplans im System zu erzwingen:

• Führen Sie sys.sp_query_store_force_plan aus.

• Erweitern Sie in SQL Server Management Studio (SSMS) den Knoten für Ihren Abfragespeicher, klicken Sie mit der rechten Maustaste auf Knoten mit dem höchsten Ressourcenverbrauch, und wählen Sie Knoten mit dem höchsten Ressourcenverbrauch anzeigen aus. Es werden die Schaltflächen Plan erzwingen und Erzwingung des Plans aufhebenangezeigt.

Weitere Informationen zum Abfragespeicher finden Sie unter Überwachen der Leistung mithilfe des Abfragespeichers.

Konstantenfaltung und Ausdrucksauswertung während der Kardinalitätsschätzung

Die Datenbank-Engine wertet bestimmte konstante Ausdrücke frühzeitig aus, um die Abfrageleistung zu steigern. Dies wird als Reduktion konstanter Ausdrücke bezeichnet. Eine Konstante ist ein Transact-SQL-Literal, z. B. 3, 'ABC', '2005-12-31', 1.0e3 oder 0x12345678. Weitere Informationen finden Sie unter Constant Folding.

Außerdem werden einige Ausdrücke, für die keine Konstantenfaltung erfolgt, deren Argumente jedoch zur Kompilierzeit bekannt sind, unabhängig davon, ob es sich bei den Argumenten um Parameter oder Konstanten handelt, während der Optimierung vom Schätzer für die Größe der Ergebnismenge (Kardinalität) ausgewertet, der Teil des Abfrageoptimierers ist. Weitere Informationen finden Sie unter Auswertung von Ausdrücken.

Bewährte Methoden: Verwendung von Konstantenfaltung und Ausdrucksauswertung zur Kompilierzeit zur Erstellung optimaler Abfragepläne

Um optimale Abfragepläne zu generieren, sollten Sie Ihre Abfragen, gespeicherten Prozeduren und Batches so entwerfen, dass der Abfrageoptimierer die Selektivität der Abfragebedingungen auf der Grundlage der Statistiken zur Datenverteilung genau schätzen kann. Anderenfalls muss der Abfrageoptimierer bei der Schätzung der Selektivität eine Standardschätzung verwenden.

Um sicherzustellen, dass der Kardinalitätsschätzer des Abfrageoptimierers gute Schätzungen liefert, sollten Sie zunächst sicherstellen, dass die AUTO_CREATE_STATISTICS und AUTO_UPDATE_STATISTICS Datenbankoptionen SET auf ON gesetzt sind (die Standardeinstellung), oder dass Sie manuell Statistiken für alle Spalten erstellt haben, auf die in einer Abfragebedingung Bezug genommen wird. Beim Entwerfen der Abfragebedingungen sollten Sie nach Möglichkeit Folgendes beachten:

• Vermeiden Sie den Einsatz lokaler Variablen in Abfragen. Verwenden Sie stattdessen in der Abfrage Parameter, Literale oder Ausdrücke.

• Beschränken Sie die Verwendung von in eine Abfrage eingebetteten Operatoren und Funktionen, die einen Parameter enthält, auf die unter „Auswertung von Ausdrücken zur Kompilierzeit für die Kardinalitätsschätzung“ aufgeführten Operatoren und Funktionen.

• Stellen Sie sicher, dass ausschließlich konstante Ausdrücke in der Bedingung Ihrer Abfrage entweder konstant faltbar sind oder zur Kompilierzeit ausgewertet werden können.

• Wenn Sie einen Ausdruck, der in einer Abfrage verwendet werden soll, mit einer lokalen Variable auswerten müssen, sollten Sie ihn in einem anderen Umfang als der Abfrage auswerten. Beispielsweise könnte es sich lohnen, eine der folgenden Optionen auszuführen:

  • Übergeben Sie den Wert der Variable an eine gespeicherte Prozedur, welche die Abfrage enthält, die Sie auswerten möchten, und verwenden Sie den Prozedurparameter anstelle einer lokalen Variablen.

  • Erstellen Sie eine Zeichenfolge, die eine teilweise auf dem Wert der lokalen Variable basierende Abfrage enthält, und führen Sie die Zeichenfolge mithilfe von dynamischem SQL-Code aus (EXEC oder sp_executesql).

  • Parametrisieren Sie die Abfrage, und führen Sie sie mithilfe von sp_executesql aus. Übergeben Sie den Wert der Variable als Parameter an die Abfrage.

Beispiele für CE-Verbesserungen

Dieser Abschnitt beschreibt Beispielabfragen, die von den in den letzten Releases in der CE implementierten Verbesserungen profitieren. Hierbei handelt es sich um Hintergrundinformationen, die keine bestimmte Aktion Ihrerseits erfordern.

Beispiel A. CE erkennt, dass der Maximalwert höher sein könnte als bei der letzten Erfassung der Statistiken

Angenommen, die Statistiken für OrderTable wurden zuletzt am 2016-04-30 erfasst, als der Höchstwert für OrderAddedDate2016-04-30 betrug. Bei der Kardinalitätsschätzung 120 (und höher) wird berücksichtigt, dass Spalten in OrderTable mit ansteigenden Daten Werte aufweisen können, die über dem von der Statistik aufgezeichneten Maximalwert liegen. Dieses Verständnis verbessert den Abfrageplan für Transact-SQL SELECT Anweisungen wie die folgende.

SELECT CustomerId, OrderAddedDate
FROM OrderTable
WHERE OrderAddedDate >= '2016-05-01';

Beispiel B. CE geht davon aus, dass gefilterte Prädikate in derselben Tabelle häufig korreliert sind.

Im Folgenden SELECT sehen wir gefilterte Prädikate auf Model und ModelVariant. Wenn der Model-Wert „Xbox“ lautet, wird intuitiv verstanden, dass die Möglichkeit besteht, dass der ModelVariant-Wert „One“ lautet, da es von „Xbox“ eine Variante namens „One“ gibt.

Ab CE 120 geht SQL Server davon aus, dass zwischen den beiden Spalten derselben Tabelle, Model und ModelVariant, eine Korrelation bestehen könnte. Der CE liefert eine genauere Schätzung, wie viele Zeilen von der Abfrage zurückgegeben werden, und der Abfrageoptimierer erstellt einen optimaleren Plan.

SELECT Model, Purchase_Price
FROM dbo.Hardware
WHERE Model = 'Xbox' AND
ModelVariant = 'Series X';

Beispiel C. CE geht nicht mehr von einer jeglichen Korrelation zwischen gefilterten Prädikaten aus verschiedenen Tabellen aus

Umfangreiche neue Untersuchungen moderner Arbeitsauslastungen und realer Geschäftsdaten haben ergeben, dass Prädikatfilter aus unterschiedlichen Tabellen üblicherweise nicht korrelieren. In der folgenden Abfrage nimmt der Kardinalitätsschätzer an, dass zwischen s.type und r.date keine Korrelation besteht. Daher schätzt die CE die Anzahl der zurückgegebenen Zeilen niedriger ein.

SELECT s.ticket, s.customer, r.store
FROM dbo.Sales AS s
CROSS JOIN dbo.Returns AS r
WHERE s.ticket = r.ticket AND
s.type = 'toy' AND
r.date = '2016-05-11';

Verwandte Inhalte

• Feedback zur Schätzung der Kardinalität (CE)
• Überwachen und Optimieren der Leistung
• Optimieren Ihrer Abfragepläne mit der SQL Server 2014-Kardinalitätsschätzung
• Abfragehinweise (Transact-SQL)
• USE HINT-Abfragehinweise
• Aktualisieren von Datenbanken mithilfe des Abfrageoptimierungs-Assistenten
• Überwachen der Leistung mithilfe des Abfragespeichers
• Leitfaden zur Architektur der Abfrageverarbeitung
• Abfragespeicher-Hinweise
• Intelligente Abfrageverarbeitung in SQL-Datenbanken
• Einrichten von Trace-Flags mit DBCC TRACEON (Transact-SQL)
• sys.query_store_query_hints