Partitionierte Tabellen und Indizes

2025-07-15

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

SQL Server, Azure SQL Database und Azure SQL Managed Instance unterstützen die Partitionierung von Tabellen und Indizes. Die Daten der partitionierten Tabellen und Indizes sind in Einheiten unterteilt, die in mehreren Dateigruppen in einer Datenbank verteilt oder in einer einzelnen Dateigruppe gespeichert werden können. Wenn mehrere Dateien in einer Dateigruppe vorhanden sind, werden die Daten mithilfe des proportionalen Füllalgorithmus auf die 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 Version von SQL Server verfügbar. Eine Liste der Funktionen, die von den SQL Server-Editionen unterstützt werden, finden Sie unter Editionen und unterstütze Funktionen von SQL Server 2022. Partitionierte Tabellen und Indizes sind in allen Service-Tiers von Azure SQL Database und Azure SQL Managed Instances verfügbar.

Das Partitioning von Tabellen ist auch in dedizierten SQL Pools in Azure Synapse Analytics verfügbar, mit einigen Unterschieden in der Syntax. Erfahren Sie mehr unter Partitioning von Tabellen in dedizierten SQL Pools.

Wichtig

Die Datenbank-Engine unterstützt standardmäßig bis zu 15.000 Partitionen. In Versionen vor SQL Server 2012 (11.x) war die Anzahl der Partitionen standardmäßig auf 1.000 begrenzt.

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 Aufbewahrungsoperationen auf einer oder mehreren Partitionen schneller durchführen. Die Vorgänge sind effizienter, da sie auf nur diese Datenteilmengen abzielen, statt auf die ganze Tabelle. So können Sie beispielsweise Daten in einer oder mehreren Partitionen komprimieren, eine oder mehrere Partitionen eines Index neu erstellen oder Daten in einer einzelnen Partition kürzen. Sie können auch einzelne Partitionen aus einer Tabelle und in eine Archivtabelle wechseln.
Sie können die Abfrageleistung verbessern, basierend auf den Arten von Abfragen, die Sie häufig ausführen. So kann der Abfrageoptimierer zum Beispiel equijoin-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 im Abschnitt zu Abfragen.

Darüber hinaus kann die Leistung 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

Hierbei handelt es sich um 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. Wenn Sie beispielsweise eine Tabelle mit Verkaufsauftragsdaten enthalten, können Sie die Tabelle basierend auf einer Datetime-Spalte wie z. B. einem Verkaufsdatum in 12 (monatliche) Partitionen aufteilen.

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

Ein LEFT-Bereich gibt an, dass der Begrenzungswert zur linken Seite des Begrenzungswertintervalls gehört, wenn die Intervallwerte von der Datenbank-Engine in aufsteigender Reihenfolge von links nach rechts sortiert werden. Mit anderen Worten, der höchste Begrenzungswert wird in eine Partitioning aufgenommen.
Ein RIGHT-Bereich gibt an, dass der Begrenzungswert zur rechten Seite des Begrenzungswertintervalls gehört, wenn die Intervallwerte von der Datenbank-Engine in aufsteigender Reihenfolge von links nach rechts sortiert werden. Mit anderen Worten: Der niedrigste Begrenzungswert wird in jede Partitioning aufgenommen.

Wenn LINKS oder RECHTS nicht angegeben wird, ist der LINKS-Bereich die Vorgabe.

Die folgende Partitionsfunktion partitioniert 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 RIGHT-Bereich bedeutet, dass die Begrenzungswerte in jeder Partition als untere Begrenzungswerte verwendet werden. RIGHT-Bereiche sind oft einfacher zu handhaben, wenn Sie eine Tabelle auf der Basis einer Spalte des Datentyps Datetime oder Datetime2 partitionieren, da Zeilen mit einem Wert von Mitternacht in derselben Partition gespeichert werden wie Zeilen mit späteren Werten am selben Tag. Ähnlich verhält es sich bei der Verwendung des Datentyps Datum und bei Partitionen von einem Monat oder mehr. Ein RIGHT-Bereich hält den ersten Tag des Monats in derselben Partition wie spätere Tage in diesem Monat. Dies hilft bei der präzisen Eliminierung von Partitionen, wenn Sie die Daten eines ganzen Tages abfragen.

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 Begrenzungspunkt und dient somit als untere Grenze der Partition 2.

Partitionierung	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`

Sowohl für RANGE LEFT als auch für RANGE RIGHT gilt für die linke Partition der Minimalwert des Datentyps als untere Grenze und für die rechte Partition der Maximalwert des Datentyps als obere Grenze.

Weitere Beispiele zu den Partitionsfunktionen LEFT und RIGHT finden Sie in CREATE PARTITION FUNCTION.

Partitionsschema

Ein Partitionsschema ist ein Datenbankobjekt, das die Partitionen einer Partitionsfunktion einer Dateigruppe oder mehreren Dateigruppen zuordnet.

Hier finden Sie Beispielsyntax zum Erstellen von Partitionsschemas in CREATE PARTITION SCHEME.

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. Bei der Verwendung von Tiered Storage können Sie mit Hilfe mehrerer Dateigruppen bestimmte Partitionen bestimmten Storage-Tiers zuweisen, um z.B. ältere Partitionen, auf die weniger häufig zugegriffen wird, auf langsamerem und kostengünstigerem Storage abzulegen. 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 zu administrativen Aufgaben erheblicher Komplexität führen. Wenn Ihre Verfahren zur Sicherung und Wiederherstellung nicht von der Verwendung mehrerer Dateigruppen profitieren, wird eine einzige Dateigruppe für alle Partitionen empfohlen. Die gleichen Regeln für das Entwerfen von Dateien und Dateigruppen gelten für partitionierte Objekte wie für nicht partitionierte Objekte.

Hinweis

Partitioning wird in Azure SQL Database nicht vollständig unterstützt. Da in Azure SQL Database nur die PRIMARY-Dateigruppe unterstützt wird, müssen alle Partitionen in der PRIMARY-Dateigruppe abgelegt werden.

Beispielcode zum Erstellen von Dateigruppen für SQL Server und Azure SQL Managed Instance finden Sie unter ALTER DATABASE (Transact-SQL) Datei- und Dateigruppenoptionen.

Partitionierungsspalte

Die Spalte einer Tabelle oder eines Indexes, die von einer Partitionsfunktion zum Partitionieren der Tabelle oder des Indexes verwendet wird. Bei der Auswahl einer Partitioning-Spalte sind die folgenden Überlegungen anzustellen:

Berechnete Spalten, die in eine Partitionsfunktion einbezogen werden, müssen explizit als PERSISTED erstellt sein.
- Da nur eine Spalte als Partitioning-Spalte verwendet werden kann, kann in einigen Fällen die Verkettung mehrerer Spalten mit einer berechneten Spalte sinnvoll sein.
Spalten aller Datentypen, die für die Verwendung als Indexschlüsselspalten zulässig sind, können als Partitioning-Spalte verwendet werden, außer Zeitstempel.
Spalten von großen Objekt-Datentypen (LOB) wie z. B. ntext, text, image, xml, varchar(max), nvarchar(max) und varbinary(max) können nicht angegeben werden.
Microsoft .NET Framework Common Language Runtime (CLR) benutzerdefinierte Typ- und Alias-Datentypspalten können nicht angegeben werden.

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

Wenn bei der Erstellung eines nicht geclusterten Indexes partition_scheme_name oder filegroup nicht angegeben wird und die Tabelle partitioniert ist, wird der Index im gleichen Partitionsschema unter Verwendung der gleichen Partitioning-Spalte wie die zugrunde liegende Tabelle platziert. Um zu ändern, wie ein vorhandener Index partitioniert wird, verwenden Sie CREATE INDEX mit der DROP_EXISTING Klausel. Auf diese Weise können Sie einen nicht partitionierten Index partitionieren, einen partitionierten Index in einen nicht partitionierten umwandeln oder das Partitionsschema eines Indexes ändern.

Ausgerichteter Index

Ein Index, der auf dem gleichen Partitionsschema wie die zugehörige Tabelle aufbaut. Wenn eine Tabelle und ihre Indizes aufeinander abgestimmt sind, kann die Datenbank-Engine schnell und effizient Partitionen in der Tabelle oder aus der Tabelle heraus ändern und dabei 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 Sie einen nicht eindeutigen geclusterten Index partitionieren und die Partitioning-Spalte nicht explizit im Cluster-Schlüssel angegeben ist, fügt die Datenbank-Engine die Partitioning-Spalte standardmäßig zur Liste der Schlüssel des geclusterten Index 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-Engine fügt die Partitioning-Spalte 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 Partitionierungsschema, das ihn in einer anderen Dateigruppe oder einem anderen Set von Dateigruppen als die Basistabelle festlegt. Das Entwerfen eines nicht ausgerichteten partitionierten Indexes kann in den folgenden Fällen hilfreich 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 Beseitigung von Partitionen und verwandte Konzepte in Erweiterungen der Abfrageverarbeitung bei partitionierten Tabellen und Indizes.

Einschränkungen

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 NULLs in der Partitioning-Spalte enthalten, werden diese Zeilen in der Partition ganz links platziert. Wenn jedoch NULL als erster Begrenzungswert und RANGE RIGHT in der Definition der Partitioning-Funktion angegeben ist, bleibt die Partition ganz links leer und die NULLs werden in der zweiten Partition platziert.

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 Speicher, partitionierte Indexoperationen, DBCC-Befehle und Abfragen. Dieser Abschnitt beschreibt die Auswirkungen der Verwendung von mehr als 1.000 Partitionen auf die Leistung und bietet bei Bedarf Umgehungsmöglichkeiten.

Mit der Möglichkeit, bis zu 15.000 Partitionen pro partitionierter Tabelle oder Index zu verwenden, können Sie Daten über lange Zeiträume in einer einzigen 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 genügend Arbeitsspeicher verfügt, können DML-Anweisungen (Data Manipulation Language), DDL-Anweisungen (Data Definition Language) und andere Vorgänge aufgrund unzureichendem Arbeitsspeicher fehlschlagen. Systeme mit 16 GB RAM, die viele arbeitsspeicherintensive Prozesse ausführen, können bei Vorgängen, die auf einer großen Anzahl von Partitionen ausgeführt werden, nicht genügend Arbeitsspeicher haben. 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) Server-Konfigurationsoption erhöhen. Weitere Informationen finden Sie unter Serverkonfiguration: Indexerstellungsspeicher. Für Azure SQL Database sollten Sie in Erwägung ziehen, das Servicelevel-Ziel für die Datenbank im Azure-Portal vorübergehend oder dauerhaft zu erhöhen, um mehr Speicher zuzuweisen.

Vorgänge für partitionierte Indizes

Das Erstellen und Neuerstellen nicht ausgerichteter Indizes in einer Tabelle mit mehr als 1.000 Partitionen ist möglich, wird jedoch 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 ausgrichteten Indizes kann um so länger dauern, je mehr Partitionen hinzugefügt werden. Es wird empfohlen, nicht mehrere Erstellungs- und Neuerstellungsindexbefehle gleichzeitig auszuführen, da Leistungs- und Speicherprobleme auftreten können.

Wenn die Datenbank-Engine Sortiervorgänge zum Erstellen partitionierter Indizes durchführt, erstellt es zuerst eine Sortiertabelle für jede Partition. Anschließend werden die Sortiertabellen entweder in der jeweiligen Dateigruppe der einzelnen Partitionen oder in tempdb erstellt, wenn die Indexoption SORT_IN_TEMPDB angegeben ist. 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 Speicher verfügbar ist, wird der Buildvorgang erfolgreich ausgeführt, die Leistung kann jedoch beeinträchtigt werden. 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.

Für ausgerichtete und nicht ausgerichtete Indizes kann die Speicheranforderung größer sein, wenn das Datenbankmodul Abfrageparallelität zum Buildvorgang auf einem Multiprozessorcomputer verwendet. Denn je höher die Grade der Parallelität (DOP) sind, desto größer ist auch der Arbeitsspeicherbedarf. Wenn die Datenbank-Engine z. B. die Grade 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 16.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 kann die Ausführung von DBCC-Befehlen wie z. B. DBCC CHECKDB und DBCC CHECKTABLE länger dauern, da die Anzahl der Partitionen steigt.

Abfragen

Nach der Partitionierung einer Tabelle oder eines Index können Abfragen, die Partitionen eliminieren, bei einer größeren Anzahl von Partitionen eine vergleichbare oder verbesserte Leistung aufweisen. 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 Aunterteilt.
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. Dieselbe Abfrage kann in Szenario 2 schneller ausgeführt werden, da es weniger Zeilen gibt, die in einer Partition gescannt werden müssen. Eine Abfrage, die über eine WHERE-Klausel verfügt, die nach Spalte B filtert, scannt alle Partitionen. Die Abfrage kann in Szenario 1 schneller ausgeführt werden als in Szenario 2, da weniger Partitionen zum Scannen vorhanden sind.

Abfragen, die Operatoren wie TOP oder MAX/MIN für andere Spalten als die Partitionierungsspalte verwenden, können bei der Partitionierung die Leistung verringern, 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 die Partitionierungsspalte nicht enthält, da sie so viele Suchvorgänge oder Scans ausführen muss, wie Partitionen vorhanden sind. Aus diesem Grund verbessert Partitioning die Leistung in OLTP-Systemen, in denen solche Abfragen üblich sind, nur selten.

Wenn Sie häufig Abfragen ausführen, die equijoin 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 verschiedene 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 miteinander verknüpft sind oder nicht auf dem Verknüpfungsfeld partitioniert werden, wird die Abfrageverarbeitung möglicherweise durch das Vorhandensein von Partitionen möglicherweise verlangsamt, anstatt sie zu beschleunigen.

Möglicherweise ist die Verwendung $PARTITION in einigen Abfragen hilfreich. Weitere Informationen finden Sie in $PARTITION.

Weitere Informationen zur Partitionsverarbeitung in der Abfrageverarbeitung, einschließlich paralleler Abfrageausführungsstrategie für partitionierte Tabellen und Indizes sowie zusätzliche bewährte Methoden finden Sie unter "Verbesserungen der Abfrageverarbeitung" in partitionierten Tabellen und Indizes.

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

In Azure SQL Database, Azure SQL Managed Instance und SQL Server 2012 (11.x) und höher werden Statistiken nicht durch das Scannen aller Zeilen in der Tabelle erstellt, wenn ein partitionierter Index erstellt oder neu aufgebaut 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 in 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.