Partitionierte Tabellen und Indizes

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance

SQL Server, Azure SQL-Datenbank und Azure SQL Managed Instance unterstützen Tabellen- und Indexpartitionierung. Die Daten partitionierter Tabellen und Indizes werden in Einheiten aufgeteilt, die über mehrere Dateigruppen in einer Datenbank verteilt oder in einer einzelnen Dateigruppe gespeichert sein können. Wenn mehrere Dateien in einer Dateigruppe vorhanden sind, werden Daten mithilfe des Algorithmus zur proportionalen Füllung auf Dateien verteilt. Die Daten werden horizontal partitioniert, sodass Gruppen von Zeilen einzelnen Partitionen zugeordnet werden. Alle Partitionen eines einzelnen Indexes oder einer Tabelle müssen sich in der gleichen Datenbank befinden. Die Tabelle oder der Index wird als einzelne logische Entität behandelt, wenn Abfragen oder Aktualisierungen für die Daten ausgeführt werden.

Vor SQL Server 2016 (13.x) SP1 waren partitionierte Tabellen und Indizes nicht in jeder Edition von SQL Server verfügbar. Eine Liste der Funktionen, die von den SQL Server-Editionen unterstützt werden, finden Sie unter Editionen und unterstützte Funktionen von SQL Server 2022. Partitionierte Tabellen und Indizes sind in allen Dienstebenen von der Azure SQL-Datenbank und Azure SQL Managed Instance verfügbar.

Die Tabellenpartitionierung ist auch in Dedicated SQL-Pools in Azure Synapse Analytics mit einigen Syntaxunterschieden verfügbar. Weitere Informationen finden Sie in Partitionierungstabellen im Dedicated SQL-Pool.

Wichtig

Die Datenbank-Engine unterstützt standardmäßig bis zu 15.000 Partitionen. In früheren Versionen als SQL Server 2012 (11.x) wurde die Anzahl der Partitionen standardmäßig auf 1.000 beschränkt.

Vorteile der Partitionierung

Das Partitionieren großer Tabellen oder Indizes kann die folgenden Vorteile bei der Verwaltung und Leistung haben.

  • Sie können Teilmengen von Daten schnell und effizient übertragen und darauf zugreifen, während die Integrität der Datensammlung erhalten bleibt. So dauert beispielsweise ein Vorgang wie das Laden von Daten von einem OLTP-System in ein OLAP-System nur Sekunden, statt Minuten und Stunden, wenn die Daten nicht partitioniert sind.

  • Sie können Wartungs- oder Datenaufbewahrungsvorgänge für eine oder mehrere Partitionen schneller ausführen. Die Vorgänge sind effizienter, da sie auf nur diese Datenteilmengen abzielen, statt auf die ganze Tabelle. Sie können z. B. wählen, Daten in einer oder mehreren Partitionen zu komprimieren, eine oder mehrere Partitionen eines Indexes neu zu erstellen oder Daten in einer einzelnen Partition abzuschneiden. Sie können auch einzelne Partitionen aus einer Tabelle in eine Archivtabelle tauschen.

  • Sie können die Abfrageleistung basierend auf den Arten von Abfragen verbessern, die Sie häufig ausführen. Beispielsweise kann der Abfrageoptimierer zum Beispiel Gleichheitsverknüpfungs-Abfragen zwischen zwei oder mehreren partitionierten Tabellen schneller verarbeiten, wenn die Partitionierungsspalten mit den Spalten identisch sind, über die die Tabellen verknüpft werden. Weitere Informationen finden Sie weiter unten unter Abfragen.

Die Leistung kann verbessert werden, indem eine Sperrenausweitung auf Partitionsebene statt auf die gesamte Tabelle angewendet wird. Dies kann Sperrenkonflikte für die Tabelle reduzieren. Setzen Sie die LOCK_ESCALATION-Option der ALTER TABLE-Anweisung auf AUTO, um eine Sperrenausweitung auf die Partition zuzulassen und damit Sperrenkonflikte zu verringern.

Komponenten und Konzepte

Die folgenden Begriffe beziehen sich auf die Tabellen- und Indexpartitionierung.

Partitionsfunktion

Eine Partitionsfunktion ist ein Datenbankobjekt, das definiert, wie die Zeilen einer Tabelle oder eines Index basierend auf den Werten einer bestimmten Spalte, einer sogenannten Partitionierungsspalte, mehreren Partitionen zugeordnet werden. Bei den einzelnen Werten in der Partitionierungsspalte handelt es sich um eine Eingabe für die Partitionsfunktion, die einen Partitionswert zurückgibt.

Die Partitionsfunktion definiert die Anzahl von Partitionen sowie die Begrenzungen der Partitionen, über die die Tabelle verfügt. Angenommen, Sie verfügen über eine Tabelle, die Verkaufsauftragsdaten enthält, und möchten die Tabelle möglicherweise in 12 (monatliche) Partitionen auf Grundlage einer datetime -Spalte (z.B. Verkaufsdatum) partitionieren.

Ein Bereichstyp (entweder LINKS oder RECHTS) gibt an, wie die Grenzwerte der Partitionsfunktion in die resultierenden Partitionen eingefügt werden:

  • Ein Bereich LINKS gibt an, dass der Grenzwert zur linken Seite des Grenzwertintervalls gehört, wenn Intervallwerte von der Datenbank-Engine in aufsteigender Reihenfolge von links nach rechts sortiert werden. Anders ausgedrückt, der höchste Begrenzungswert wird in einer Partition eingeschlossen.
  • Ein Bereich RECHTS gibt an, dass der Grenzwert zur rechten Seite des Grenzwertintervalls gehört, wenn Intervallwerte von der Datenbank-Engine in aufsteigender Reihenfolge von links nach rechts sortiert werden. Anders ausgedrückt, der niedrigste Begrenzungswert wird in jeder Partition eingeschlossen.

Wenn LINKS oder RECHTS nicht angegeben ist, ist der Bereich LINKS die Standardeinstellung.

Die folgende Partitionsfunktion partitioniert beispielsweise eine Tabelle oder einen Index in 12 Partitionen, d. h. eine für die Menge an Werten eines jeden Monats des Jahres in einer datetime-Spalte. Ein Bereich RECHTS wird verwendet, der angibt, dass Grenzwerte in jeder Partition als untere Begrenzungswerte dienen. Bereiche RECHTS sind häufig einfacher zu bearbeiten, wenn eine Tabelle basierend auf einer Spalte mit den Datentypen datetime oder datetime2 partitioniert wird, da Zeilen mit einem Wert von Mitternacht in derselben Partition wie Zeilen mit späteren Werten am selben Tag gespeichert werden. Ebenso behält ein Bereich RECHTS bei Verwendung des Datentyps date und der Partitionen eines Monats oder mehrerer Partitionen den ersten Tag des Monats in derselben Partition wie spätere Tage in diesem Monat bei. Dies hilft bei der genauen Partitionsentfernung beim Abfragen des gesamten Datenwerts eines ganzen Tages.

CREATE PARTITION FUNCTION [myDateRangePF1] (datetime)  
AS RANGE RIGHT FOR VALUES ('2022-02-01', '2022-03-01', '2022-04-01',  
               '2022-05-01', '2022-06-01', '2022-07-01', '2022-08-01',   
               '2022-09-01', '2022-10-01', '2022-11-01', '2022-12-01');

In der folgenden Tabelle wird dargestellt, wie eine Tabelle oder ein Index, die bzw. der diese Partitionsfunktion auf der datecol-Partitionierungsspalte verwendet, partitioniert wird. Der 1. Februar ist der erste in der Funktion definierte Grenzpunkt, wodurch er als untere Grenze der Partition 2 fungiert.

Partition 1 2 ... 11 12
Werte datecol<2022-02-01 12:00AM datecol>= 2022-02-01 12:00AM AND datecol<2022-03-01 12:00AM datecol>= 2022-11-01 12:00AM AND col1<2022-12-01 12:00AM datecol>= 2022-12-01 12:00AM

Für BEREICH LINKS und BEREICH RECHTS weist die äußerste linke Partition den Minimalwert des Datentyps als untere Grenze auf, und die äußerste rechte Partition hat den Maximalwert des Datentyps als oberer Grenzwert.

Weitere Beispiele für die Partitionsfunktionen LINKS und RECHTS in finden Sie in CREATE PARTITION FUNCTION (Transact-SQL).

Partitionsschema

Bei einem Partitionsschema handelt es sich um ein Datenbankobjekt, das die Partitionen einer Partitionsfunktion einer Dateigruppe oder mehreren Dateigruppen zuordnet.

Beispielsyntax zum Erstellen von Partitionsschemas finden Sie in CREATE PARTITION SCHEME (Transact-SQL).

Dateigruppen

Der wichtigste Grund dafür, dass Partitionen in separaten Dateigruppen platziert werden, besteht darin, sicherzustellen, dass Sie Sicherungs- und Wiederherstellungsvorgänge unabhängig für Partitionen ausführen können. Dies liegt daran, dass Sie Sicherungen für einzelne Dateigruppen ausführen können. Wenn Sie mehrstufigen Speicher verwenden, können Sie mithilfe mehrerer Dateigruppen bestimmte Partitionen bestimmten Speicherebenen zuweisen, z. B. um ältere und seltener verwendete Partitionen auf langsameren und kostengünstigeren Speicher zu platzieren. Alle anderen Partitionierungsvorteile gelten unabhängig von der Anzahl der verwendeten Dateigruppen oder der Platzierung von Partitionen in bestimmten Dateigruppen.

Das Verwalten von Dateien und Dateigruppen für partitionierte Tabellen kann im Laufe der Zeit die Komplexität der administrativen Aufgaben deutlich erhöhen. Wenn Ihre Vorgehensweisen für die Sicherung und Wiederherstellung nicht von der Verwendung mehrerer Dateigruppen profitieren, wird eine einzelne Dateigruppe für alle Partitionen empfohlen. Die gleichen Regeln für das Entwerfen von Dateien und Dateigruppen gelten für partitionierte wie für nicht partitionierte Objekte.

Hinweis

Die Partitionierung wird in Azure SQL-Datenbank nicht vollständig unterstützt. Da nur die PRIMARY-Dateigruppe in der Azure SQL-Datenbank unterstützt wird, müssen alle Partitionen in der PRIMARY-Dateigruppe platziert werden.

Finden Sie Beispielcode zum Erstellen von Dateigruppen für SQL Server und Azure SQL Managed Instance in ALTER DATABASE-Optionen für Dateien und Dateigruppen (Transact-SQL).

Partitionierungsspalte

Die Spalte einer Tabelle oder eines Indexes, die von einer Partitionsfunktion zum Partitionieren der Tabelle oder des Indexes verwendet wird. Die folgenden Überlegungen gelten für das Auswählen einer Partitionierungsspalte:

  • Berechnete Spalten, die in eine Partitionsfunktion einbezogen werden, müssen explizit als PERSISTED erstellt werden.
    • Da nur eine Spalte als Partitionsspalte eingesetzt werden kann, kann die Verkettung mehrerer Spalten mit einer berechneten Spalte hilfreich sein.
  • Spalten aller Datentypen, die zum Verwenden als Index-Schlüsselspalten zulässig sind, können als Partitionsspalte verwenden werden, mit Ausnahme des Datentyps timestamp.
  • Spalten mit LOB-Datentypen (Large Object) wie ntext, text, image, xml, varchar(max), nvarchar(max) oder varbinary(max) können nicht angegeben werden.
  • Der benutzerdefinierte CLR-Typ (Common Language Runtime) von Microsoft .NET Framework und die Spalten können mit dem Aliasdatentyp nicht angegeben werden.

Um ein Objekt zu partitionieren, geben Sie das Partitionsschema und Partitionierungsspalte in den Anweisungen CREATE TABLE (Transact-SQL), ALTER TABLE (Transact-SQL) und CREATE INDEX (Transact-SQL) an.

Wenn beim Erstellen eines nicht gruppierten Indexes partition_scheme_name oder die Dateigruppe bei einer partitionierten Tabelle nicht angegeben werden, wird der Index im selben Partitionsschema platziert, und er verwendet dieselbe Partitionierungsspalte wie die zugrunde liegende Tabelle. Nutzen Sie CREATE INDEX mit der Klausel DROP_EXISTING, um die Partitionierung eines vorhandenen Indexes zu ändern. Auf diese Weise können Sie einen nicht partitionierten Index partitionieren, einen partitionierten Index nicht partitionieren oder das Partitionsschema des Indexes ändern.

Ausgerichteter Index

Ein Index, der auf dem gleichen Partitionsschema wie die zugehörige Tabelle aufbaut. Wenn eine Tabelle und ihre Indizes aneinander ausgerichtet sind, kann die Datenbank-Engine schnell zwischen Partitionen innerhalb und außerhalb der Tabelle wechseln und gleichzeitig die Partitionsstruktur sowohl der Tabelle als auch ihrer Indizes beibehalten. Ein Index muss nicht an derselben benannten Partitionsfunktion beteiligt sein, um an ihrer Basistabelle ausgerichtet zu sein. Allerdings müssen die Partitionsfunktionen des Indexes und der Basistabelle im Wesentlichen identisch sein, d.h.:

  • Die Argumente der Partitionsfunktionen müssen denselben Datentyp besitzen.
  • Sie definieren dieselbe Anzahl an Partitionen.
  • Sie definieren dieselben Begrenzungswerte für Partitionen.

Partitionieren gruppierter Indizes

Beim Partitionieren eines gruppierten Index muss der Gruppierungsschlüssel die Partitionierungsspalte enthalten. Wenn beim Partitionieren eines nicht eindeutigen gruppierten Index die Partitionierungsspalte nicht explizit im Gruppierungsschlüssel angegeben ist, fügt die Datenbank-Engine die Partitionierungsspalte standardmäßig zur Liste der gruppierten Indexschlüssel hinzu. Wenn der gruppierte Index eindeutig ist, müssen Sie explizit angeben, dass der gruppierte Indexschlüssel die Partitionierungsspalte enthält. Weitere Informationen zu gruppierten Indizes und zur Indexarchitektur finden Sie unter Richtlinien für den Entwurf gruppierter Indizes.

Partitionieren nicht gruppierter Indizes

Beim Partitionieren eines eindeutigen nicht gruppierten Index muss der Indexschlüssel die Partitionierungsspalte enthalten. Beim Partitionieren eines nicht eindeutigen, nicht gruppierten Index fügt die Datenbank-Engine die Partitionierungsspalte standardmäßig als eine Nichtschlüsselspalte (eingeschlossene Spalte) des Indexes hinzu, um sicherzustellen, dass der Index an der Basistabelle ausgerichtet ist. Die Datenbank-Engie fügt die Partitionierungsspalte nicht zum Index hinzu, wenn sie bereits im Index vorhanden ist. Weitere Informationen zu nicht gruppierten Indizes und zur Indexarchitektur finden Sie unter Entwurfsrichtlinien für einen nicht gruppierten Index.

Nicht ausgerichteter Index

Ein nicht ausgerichteter Index wird anders als die entsprechende Tabelle partitioniert. Das heißt, der Index hat ein anderes Partitionsschema, das ihn in einer anderen Dateigruppe oder einem anderen Dateigruppensatz als die Basistabelle platziert. Das Entwerfen eines nicht ausgerichteten partitionierten Indexes kann in den folgenden Fällen nützlich sein:

  • Die Basistabelle ist nicht partitioniert.
  • Der Indexschlüssel ist eindeutig und enthält nicht die Partitionierungsspalte der Tabelle.
  • Sie möchten die Basistabelle an angeordneten Joins mit weiteren Tabellen beteiligen, die unterschiedliche Joinspalten verwenden.

Partitionsentfernung

Der Prozess, durch den der Abfrageoptimierer nur auf relevante Partitionen zugreift, um die Filterkriterien der Abfrage zu erfüllen.

Erfahren Sie mehr über die Partitionsentfernung und verwandte Konzepte in Verbesserte Abfrageverarbeitung bei partitionierten Tabellen und Indizes.

Begrenzungen

  • Der Bereich einer Partitionsfunktion und eines Schemas ist auf die Datenbank beschränkt, in der er erstellt wurde. Innerhalb der Datenbank befinden sich Partitionsfunktionen in einem von anderen Funktionen abgetrennten Namespace.

  • Wenn Zeilen in einer partitionierten Tabelle NULL-Werte in der Partitionierungsspalte enthalten, werden diese Zeilen auf der am weitesten links stehenden Partition platziert. Jedoch wenn NULL als erster Begrenzungswert sowie BEREICH RECHTS in der Funktion der Partitionsdefinition angegeben werden, bleibt die am weitesten links stehende Partition leer, und die NULL-Werte werden in der zweiten Partition eingefügt.

Leistungsrichtlinien

Die Datenbank-Engine unterstützt bis zu 15.000 Partitionen pro Tabelle oder Index. Die Verwendung von mehr als 1.000 Partitionen hat jedoch Auswirkungen auf den Arbeitsspeicher, partitionierte Indexoperationen, DBCC-Befehle und Abfragen. In diesem Abschnitt werden die Auswirkungen auf die Leistung beschrieben, wenn mehr als 1.000 Partitionen verwendet werden, und es werden mögliche Problemumgehungen bereitgestellt.

Mit bis zu 15.000 Partitionen, die pro partitionierte Tabelle oder Index zulässig sind, können Sie Daten für eine lange Dauer in einer einzelnen Tabelle speichern. Sie sollten Daten jedoch nur so lange beibehalten, wie sie benötigt werden, und darauf achten, dass die Leistung und die Anzahl der Partitionen ausgewogen ist.

Speicherauslastung und Richtlinien

Es empfiehlt sich, mindestens 16 GB Arbeitsspeicher zu verwenden, wenn eine große Anzahl von Partitionen verwendet wird. Wenn das System nicht über ausreichend Arbeitsspeicher verfügt, kann es bei DML-Anweisungen (Datenbearbeitungssprache), DDL-Anweisungen (Datendefinitionssprache) und anderen Vorgängen aufgrund ungenügenden Arbeitsspeichers zu Fehlern kommen. Bei Systemen mit 16 GB Arbeitsspeicher, die zahlreiche speicherintensive Prozesse ausführen, kann es bei Vorgängen, die für eine große Anzahl von Partitionen ausgeführt werden, zu Fehlern aufgrund von Speicherauslastung kommen. Je mehr Arbeitsspeicher Sie über die empfohlenen 16 GB hinaus verwenden, desto geringer ist die Wahrscheinlichkeit, dass Probleme mit der Leistung und Speicherauslastung auftreten.

Arbeitsspeichereinschränkungen können sich negativ auf die Leistung oder auf die Möglichkeit der Datenbank-Engine zum Erstellen eines partitionierten Index auswirken. Das gilt insbesondere für den Fall, wenn der Index nicht an seiner Basistabelle oder an deren gruppierten Index ausgerichtet ist, sofern für die Tabelle bereits ein gruppierter Index erstellt wurde.

In SQL Server und Azure SQL Managed Instance können Sie die index create memory (KB)-Serverkonfigurationsoption erhöhen. Weitere Informationen finden Sie unter Konfigurieren der Serverkonfigurationsoption Speicher für Indexerstellung. Für Azure SQL-Datenbank sollten Sie das Ziel des Servicelevels für die Datenbank im Azure-Portal vorübergehend oder dauerhaft erhöhen, um mehr Arbeitsspeicher zuzuweisen.

Vorgänge für partitionierte Indizes

Das Erstellen bzw. Neuerstellen von nicht ausgerichteten Indizes für eine Tabelle mit mehr als 1.000 Partitionen ist möglich, wird aber nicht unterstützt. Dies hätte Leistungseinbußen oder eine zu hohe Speicherauslastung während der Vorgänge zur Folge.

Das Erstellen und Neuerstellen von ausgerichteten Indizes kann umso länger dauern, je mehr Partitionen hinzugefügt werden. Es empfiehlt sich, nicht mehrere Befehle zum Erstellen und Neuerstellen von Befehlen gleichzeitig auszuführen, da es zu Leistungs- und Arbeitsspeicherproblemen kommen kann.

Wenn die Datenbank-Engine Sortiervorgänge zum Erstellen partitionierter Indizes durchführt, erstellt sie zuerst eine Sortiertabelle für jede Partition. Anschließend werden die Sortiertabellen entweder in der jeweiligen Dateigruppe jeder Partition oder in tempdb erstellt, wenn die SORT_IN_TEMPDB-Indexoption angegeben wurde. Jede Sortiertabelle setzt für ihre Erstellung eine Mindestmenge an Arbeitsspeicher voraus. Wenn Sie einen partitionierten Index erstellen, der an seiner Basistabelle ausgerichtet ist, werden alle Sortiertabellen nacheinander erstellt, was weniger Arbeitsspeicher in Anspruch nimmt. Wenn Sie allerdings einen nicht gruppierten partitionierten Index erstellen, werden alle Sortiertabellen gleichzeitig erstellt. Das heißt, es muss ausreichend Arbeitsspeicher verfügbar sein, um diese gleichzeitigen Sortiervorgänge zu verarbeiten. Je größer die Anzahl der Partitionen, desto mehr Arbeitsspeicher wird benötigt. Die Mindestgröße für jede Sortiertabelle beträgt 40 Seiten für jede Partition mit 8 Kilobyte pro Seite. So beansprucht z. B. ein nicht ausgerichteter partitionierter Index mit 100 Partitionen ausreichend Arbeitsspeicher, um 4.000 (40 * 100) Seiten gleichzeitig seriell sortieren zu können. Wenn dieser Arbeitsspeicher verfügbar ist, ist die Erstellung zwar erfolgreich, jedoch kann die Leistung darunter leiden. Wenn dieser Arbeitsspeicher nicht verfügbar ist, schlägt die Erstellung fehl. Alternativ erfordert ein ausgerichteter partitionierter Index mit 100 Partitionen nur ausreichend Arbeitsspeicher, um 40 Seiten zu sortieren, da die Sortiervorgänge nicht gleichzeitig durchgeführt werden.

Sowohl bei ausgerichteten als auch bei nicht ausgerichteten Indizes kann der Arbeitsspeicherbedarf noch höher sein, wenn die Datenbank-Engine bei einem Computer mit mehreren Prozessoren Abfrage-Parallelität beim Erstellungsvorgang verwendet. Denn je höher der Grad der Parallelität ist, desto größer ist auch der Arbeitsspeicherbedarf. Wenn die Datenbank-Engine z. B. den Grad der Parallelität auf 4 festlegt, benötigt ein nicht ausgerichteter partitionierter Index mit 100 Partitionen ausreichend Arbeitsspeicher, damit vier Prozessoren gleichzeitig jeweils 4.000 Seiten sortieren können – also 6.000 Seiten gleichzeitig. Wenn der partitionierte Index ausgerichtet ist, verringert sich der Arbeitsspeicherbedarf auf vier Prozessoren, die jeweils 40 Seiten sortieren – also 160 (4 * 40) Seiten. Sie können die MAXDOP-Indexoption verwenden, um die Grade der Parallelität manuell zu reduzieren.

DBCC-Befehle

Bei einer größeren Anzahl von Partitionen können DBCC-Befehle wie DBCC CHECKDB und DBCC CHECKTABLE mehr Zeit für die Ausführung in Anspruch nehmen, während sich die Anzahl von Partitionen erhöht.

Abfragen

Nach dem Partitionieren einer Tabelle oder eines Indexes weisen Abfragen, die Partitionsentfernung verwenden, eine vergleichbare oder verbesserte Leistung bei einer größeren Anzahl von Partitionen auf. Abfragen, die keine Partitionsentfernung verwenden, nehmen mehr Zeit für die Ausführung in Anspruch, wenn sich die Anzahl der Partitionen erhöht.

Nehmen Sie beispielsweise an, eine Tabelle hat 100 Millionen Zeilen und Spalten A, Bund C.

  • In Szenario 1 ist die Tabelle in 1.000 Partitionen der Spalte A unterteilt.
  • In Szenario 2 ist die Tabelle in 10.000 Partitionen der Spalte Aunterteilt.

Eine Abfrage der Tabelle, die über eine WHERE-Klausel verfügt, die nach Spalte A filtert, führt die Partitionsentfernung aus und scannt eine Partition. Die gleiche Abfrage wird in Szenario 2 möglicherweise schneller ausgeführt, da es weniger zu scannende Zeilen in einer Partition gibt. Eine Abfrage, die über eine WHERE-Klausel verfügt, die nach Spalte B filtert, scannt alle Partitionen. Die Abfrage wird möglicherweise in Szenario 1 schneller als in Szenario 2 ausgeführt, da weniger Partitionen gescannt werden müssen.

Abfragen, die Operatoren wie TOP oder MAX/MIN für andere Spalten als die Partitionierungsspalte verwenden, erzielen aufgrund der Partitionierung möglicherweise eine geringere Leistung, da alle Partitionen ausgewertet werden müssen.

Ebenso dauert eine Abfrage, die eine Suche mit einer Zeile oder einen kleinen Bereichsscan durchführt, länger für eine partitionierte Tabelle als für eine nicht partitionierte Tabelle, wenn das Abfrage-Prädikat nicht die Partitionierungsspalte enthält, da sie so viele Suchvorgänge oder Scans ausführen muss, wie Partitionen vorhanden sind. Aus diesem Grund verbessert die Partitionierung selten die Leistung in OLTP-Systemen, bei denen derartige Abfragen üblich sind.

Wenn Sie häufig Abfragen ausführen, die eine Gleichheitsverknüpfung zwischen mindestens zwei partitionierten Tabellen voraussetzen, sollten deren Partitionsspalten dieselben sein wie die Spalten, an denen die Tabellen verknüpft sind. Außerdem sollten die Tabellen oder deren Indizes angeordnet sein. Dies bedeutet, dass sie entweder dieselbe benannte Partitionsfunktion verwenden oder aber unterschiedliche Partitionsfunktionen, die sich in folgenden wesentlichen Punkten entsprechen:

  • Sie besitzen dieselbe Anzahl an Parametern für die Partitionierung, und die entsprechenden Parameter sind vom selben Datentyp.
  • Sie definieren dieselbe Anzahl an Partitionen.
  • Sie definieren dieselben Begrenzungswerte für Partitionen.

Dies ermöglicht dem Abfrageoptimierer, den Join schneller zu verarbeiten, da die Partitionen selbst verknüpft werden können. Wenn eine Abfrage zwei Tabellen verknüpft, die nicht angeordnet oder nicht am Joinsfeld miteinander verknüpft sind, kann das Vorhandensein von Partitionen die Abfrageverarbeitung womöglich sogar verlangsamen, anstatt zu beschleunigen.

Möglicherweise ist die Verwendung von $PARTITION in einigen Abfragen hilfreich. Weitere Informationen finden Sie unter $PARTITION (Transact-SQL).

Weitere Informationen zur Handhabung von Partitionen in der Abfrageverarbeitung, einschließlich Strategien zu paralleler Abfrageausführung für partitionierte Tabellen und Indizes sowie weitere bewährte Methoden, finden Sie unter Verbesserte Abfrageverarbeitung bei partitionierten Tabellen und Indizes.

Das Verhalten ändert sich beim Berechnen von Statistiken, während Vorgänge für partitionierte Indizes durchgeführt werden

In der Azure SQL-Datenbank, Azure SQL Managed Instance und SQL Server 2012 (11.x) und höher werden Statistiken nicht durch Scannen aller Zeilen in der Tabelle erstellt, wenn ein partitionierter Index erstellt oder neu erstellt wird. Der Abfrageoptimierer generiert stattdessen Statistiken mithilfe des Standardalgorithmus zur Stichprobenentnahme.

Nach dem Upgrade einer Datenbank mit partitionierten Indizes aus einer Version von SQL Server unter 2012 (11.x) stellen Sie möglicherweise einen Unterschied bei den Histogrammdaten für diese Indizes fest. Diese Änderung des Verhaltens kann sich auf die Abfrageleistung auswirken. Um Statistiken zu partitionierten Indizes durch das Scannen aller Zeilen in der Tabelle abzurufen, verwenden Sie CREATE STATISTICS oder UPDATE STATISTICS mit der FULLSCAN-Klausel.

Zugehöriger Inhalt

Erfahren Sie mehr über partitionierte Tabellen und Indexstrategien in den folgenden Artikeln: