Partitionierte Tabellen und Indizes

Gilt für: SQL Server (alle unterstützten Versionen) Azure SQL Datenbank-Azure SQL Managed Instance

SQL Server, Azure SQL Datenbank und Azure SQL Managed Instance die Tabellen- und Indexpartitionierung unterstützen. Die Daten von partitionierten Tabellen und Indizes sind in Einheiten unterteilt, die über mehrere Dateigruppen in einer Datenbank verteilt oder in einer einzelnen Dateigruppe gespeichert werden können. Wenn mehrere Dateien in einer Dateigruppe vorhanden sind, werden Daten über Dateien verteilt, indem der proportionale Füllalgorithmus verwendet wird. 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 Features, die von den Editionen von SQL Server unterstützt werden, finden Sie unter Editionen und unterstützte Features für SQL Server 2016. Partitionierte Tabellen und Indizes sind in allen Dienstebenen von Azure SQL Datenbank und Azure SQL Managed Instance verfügbar.

Die Tabellenpartitionierung ist auch in dedizierten SQL-Pools in Azure Synapse Analytics mit einigen Syntaxunterschieden verfügbar. Erfahren Sie mehr in Partitionierungstabellen im dedizierten SQL-Pool.

Wichtig

Das Datenbankmodul 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 beispielsweise daten in einer oder mehreren Partitionen komprimieren, eine oder mehrere Partitionen eines Indexes neu erstellen oder Daten in einer einzelnen Partition abschneiden. 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 Gleichheitsjoin-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.

Sie können die Leistung verbessern, indem Sie die Sperreskalation auf Partitionsebene anstelle einer ganzen Tabelle aktivieren. 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 Indexes einer Gruppe von Partitionen basierend auf den Werten einer bestimmten Spalte zugeordnet werden, die als Partitionierungsspalte bezeichnet wird. 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, möchten Sie die Tabelle möglicherweise in 12 (monatliche) Partitionen basierend auf einer Datumsspalte wie einem Verkaufsdatum partitionieren.

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

  • Ein LINKer Bereich gibt an, dass der Begrenzungswert zur linken Seite des Grenzwertintervalls gehört, wenn Intervallwerte vom Datenbankmodul in aufsteigender Reihenfolge von links nach rechts sortiert werden. Mit anderen Worten, der höchste Begrenzungswert wird in eine Partition eingeschlossen.
  • Ein RECHTS-Bereich gibt an, dass der Grenzwert zur rechten Seite des Grenzwertintervalls gehört, wenn Intervallwerte vom Datenbankmodul in aufsteigender Reihenfolge von links nach rechts sortiert werden. Mit anderen Worten, der niedrigste Begrenzungswert wird in jeder Partition eingeschlossen.

Wenn LINKS oder RECHTS nicht angegeben ist, ist DER LEFT-Bereich der Standard.

Beispielsweise partitioniert die folgende Partitionsfunktion eine Tabelle oder einen Index in 12 Partitionen, eine für jeden Monat der Werte eines Jahres in einer Datumszeitspalte . Ein RECHTS-Bereich wird verwendet, der angibt, dass Grenzwerte in jeder Partition als untere Begrenzungswerte dienen. Rechte Bereiche sind häufig einfacher zu arbeiten, wenn eine Tabelle basierend auf einer Spalte mit Datums- oder Datetime2-Datentypen partitioniert wird, da Zeilen mit einem Wert von Mitternacht an derselben Partition wie Zeilen mit späteren Werten am selben Tag gespeichert werden. Wenn sie den Datentyp des Datums und die Verwendung von Partitionen eines Monats oder mehr verwenden, behält ein RECHTS-Bereich den ersten Tag des Monats in derselben Partition wie spätere Tage in diesem Monat bei. Dies unterstützt die präzise Partitionsausscheidung beim Abfragen des gesamten Datenwerts.

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. 1. Februar ist der erste in der Funktion definierte Grenzpunkt, sodass 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 RANGE LEFT und RANGE RIGHT weist die linke Partition den Minimalwert des Datentyps als untere Grenze auf, und die ganz rechtsste Partition hat den maximalen Wert des Datentyps als oberer Grenzwert.

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

Partitionsschema

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

Hier finden Sie Beispielsyntax zum Erstellen von Partitionsschemas 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. Bei Verwendung von mehrstufigem Speicher können Sie mithilfe mehrerer Dateigruppen bestimmte Partitionen bestimmten Speicherebenen zuweisen, z. B. zum Platzieren älterer und weniger häufig zugegriffener Partitionen auf langsameren und weniger teuren Speicher. 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 zu administrativen Aufgaben im Laufe der Zeit erhebliche Komplexität hinzufügen. Wenn Ihre Sicherungs- und Wiederherstellungsprozeduren 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 Objekte wie für nicht partitionierte Objekte.

Hinweis

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

Hier finden Sie Beispielcode zum Erstellen von Dateigruppen für SQL Server und Azure SQL Managed Instance in 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. Die folgenden Überlegungen gelten beim Auswählen einer Partitionsspalte:

  • Berechnete Spalten, die an einer Partitionsfunktion teilnehmen, müssen explizit als PERSISTED erstellt werden.
    • Da nur eine Spalte als Partitionsspalte verwendet werden kann, kann in einigen Fällen die Verkettung mehrerer Spalten mit einer berechneten Spalte nützlich sein.
  • Spalten aller Datentypen, die für die Verwendung als Indexschlüsselspalten gültig sind, können als Partitionierungsspalte verwendet werden, mit Ausnahme des Zeitstempels.
  • Spalten von Datentypen für große Objekte (LOB), z. B. ntext, Text, Image, xml, varchar(max), nvarchar(max), und varbinary(max), können nicht angegeben werden.
  • Microsoft .NET Framework benutzerdefinierte Datentypspalten (Common Language Runtime, CLR) können nicht angegeben werden.

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

Wenn beim Erstellen eines nicht gruppierten Indexes partition_scheme_name oder Dateigruppe nicht angegeben wird und die Tabelle partitioniert wird, wird der Index in dasselbe Partitionsschema mit derselben Partitionsspalte 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 nicht partitioniert 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 deren Indizes ausgerichtet sind, kann das Datenbankmodul Partitionen schnell und effizient wechseln und gleichzeitig die Partitionsstruktur der Tabelle und deren Indizes beibehalten. Ein Index muss nicht an derselben benannten Partitionsfunktion teilnehmen, die an der Basistabelle ausgerichtet werden soll. 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.

Partitionierung gruppierter Indizes

Beim Partitionieren eines gruppierten Index muss der Gruppierungsschlüssel die Partitionierungsspalte enthalten. Beim Partitionieren eines nicht eindeutigen gruppierten Indexes und der Partitionierungsspalte wird im Clusterschlüssel nicht explizit angegeben, fügt das Datenbankmodul standardmäßig die Partitionsspalte der 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 Indexes fügt das Datenbankmodul standardmäßig die Partitionsspalte als Nichtschlüsselspalte (eingeschlossen) des Indexes hinzu, um sicherzustellen, dass der Index an der Basistabelle ausgerichtet ist. Das Datenbankmodul 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 weist ein anderes Partitionsschema auf, das es in einer separaten Dateigruppe oder einem Satz von Dateigruppen aus der 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 Partitionsausscheidung und verwandte Konzepte in Abfrageverarbeitungsverbesserungen für partitionierte 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 Partitionsspalte enthalten, werden diese Zeilen auf der linken Partition platziert. Wenn NULL jedoch als erster Grenzwert und RANGE RIGHT in der Partitionsfunktionsdefinition angegeben wird, bleibt die linksste Partition leer, und NULLs werden in der zweiten Partition platziert.

Leistungsrichtlinien

Das Datenbankmodul unterstützt bis zu 15.000 Partitionen pro Tabelle oder Index. Die Verwendung von mehr als 1.000 Partitionen hat jedoch Auswirkungen auf Arbeitsspeicher, partitionierte Indexvorgänge, DBCC-Befehle und Abfragen. In diesem Abschnitt werden die Leistungsauswirkungen der Verwendung von mehr als 1.000 Partitionen beschrieben und bei Bedarf Problemumgehungen bereitgestellt.

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

Speichernutzung 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.

Speicherbeschränkungen können sich auf die Leistung oder Fähigkeit des Datenbankmoduls auswirken, einen partitionierten Index zu erstellen. Dies ist insbesondere der Fall, wenn der Index nicht mit der Basistabelle ausgerichtet ist oder nicht mit seinem gruppierten Index ausgerichtet ist, wenn die Tabelle bereits über einen gruppierten Index verfügt.

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

Partitionierte Indexvorgänge

Das Erstellen und Erstellen 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 Neu erstellen ausgerichteter Indizes kann länger dauern, da die Anzahl der Partitionen erhöht wird. Es empfiehlt sich, nicht mehrere Befehle zum Erstellen und Neuerstellen von Befehlen gleichzeitig auszuführen, da es zu Leistungs- und Arbeitsspeicherproblemen kommen kann.

Wenn das Datenbankmodul sortiert, um partitionierte Indizes zu erstellen, erstellt es zunächst 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.

Für ausgerichtete und nicht ausgerichtete Indizes kann die Speicheranforderung größer sein, wenn das Datenbankmodul Abfrage parallelismus zum Buildvorgang auf einem Multiprozessorcomputer verwendet. Dies liegt daran, dass der Grad des Parallelismus (DOP) größer ist als die Speicheranforderung. Wenn das Datenbankmodul beispielsweise DOP auf 4 festlegt, erfordert ein nicht ausgerichteter Partitionsindex mit 100 Partitionen ausreichend Arbeitsspeicher für vier Prozessoren, um 4.000 Seiten gleichzeitig zu sortieren, oder 16.000 Seiten. 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 den Grad des Parallelismus manuell zu reduzieren.

DBCC-Befehle

Mit einer größeren Anzahl von Partitionen kann DBCC-Befehle wie DBCC CHECKDB und DBCC CHECKTABLE länger ausgeführt werden, da die Anzahl der Partitionen erhöht wird.

Abfragen

Nach der Partitionierung einer Tabelle oder eines Indexes können Abfragen, die partitionsausscheidung verwenden, vergleichbare oder verbesserte Leistung mit einer größeren Anzahl von Partitionen 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 in 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. 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 Einzelzeilensuche ausführt oder eine kleine Bereichsüberprüfung länger für eine partitionierte Tabelle als für eine nicht partitionierte Tabelle verwendet wird, wenn das Abfragededikat nicht die Partitionsspalte enthält, da sie so viele Suchvorgänge oder Scans ausführen muss, wie partitionierte Partitionen vorhanden sind. Aus diesem Grund verbessert die Partitionierung selten die Leistung in OLTP-Systemen, bei denen solche Abfragen häufig vorkommen.

Wenn Sie häufig Abfragen ausführen, die Gleichheitsjoins 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 unterschiedliche Partitionsfunktionen verwenden, die im Wesentlichen identisch sind, in diesem Fall:

  • 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 $PARTITION in einigen Abfragen hilfreich. Weitere Informationen finden Sie in $PARTITION (Transact-SQL).

Weitere Informationen zur Partitionsbehandlung in der Abfrageverarbeitung, einschließlich paralleler Abfrageausführungsstrategie für partitionierte Tabellen und Indizes sowie weitere bewährte Methoden finden Sie unter Abfrageverarbeitungsverbesserungen für partitionierte 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 Datenbank, Azure SQL Managed Instance und SQL Server 2012 (11.x) und höher werden Statistiken nicht erstellt, indem alle Zeilen in der Tabelle überprüft werden, 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 niedriger als 2012 (11.x) können Sie einen Unterschied in den Histogrammdaten für diese Indizes feststellen. 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.

Nächste Schritte

Weitere Informationen zu partitionierten Tabellen und Indexstrategien finden Sie in den folgenden Artikeln: