Partitionierte Tabellen und Indizes

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

SQL Server, Azure SQL-Datenbank und Azure SQL Managed Instance Tabellen- und Indexpartitionierung unterstützen. Die Daten von partitionierten Tabellen und Indizes werden in Einheiten unterteilt, die in mehreren Dateigruppen in einer Datenbank oder in einer einzelnen Dateigruppe gespeichert werden können. Wenn mehrere Dateien in einer Dateigruppe vorhanden sind, werden Daten über Dateien verteilt, die den proportionalen Füllalgorithmus verwenden. 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 verfügbar, wobei einige Syntaxunterschiede bestehen. Weitere Informationen finden Sie unter 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 Aufbewahrungsvorgä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 Sperrkalation 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 auf 12 (monatlichen) Partitionen basierend auf einer Datumszeitspalte 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 LINKS-Bereich gibt an, dass der Grenzwertwert zur linken Seite des Grenzwertwertintervalls gehört, wenn Intervallwerte vom Datenbankmodul in aufsteigender Reihenfolge von links nach rechts sortiert werden. Mit anderen Worten, der höchste Begrenzungswert wird in einer Partition enthalten sein.
  • Ein RECHTS-Bereich gibt an, dass der Grenzwertwert zur rechten Seite des Grenzwertwertintervalls 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 enthalten sein.

Wenn LINKS oder RECHTS nicht angegeben ist, ist LINKS der Standardbereich.

Die folgende Partitionsfunktion partitioniert beispielsweise eine Tabelle oder einen Index in 12 Partitionen, eine für jeden Monat der Werte eines Jahres in einer Datumszeitspalte . Es wird ein RECHTS-Bereich verwendet, der angibt, dass Grenzwertwerte als untere Begrenzungswerte in jeder Partition dienen. Rechtsbereiche sind häufig einfacher zu arbeiten, wenn sie eine Tabelle basierend auf einer Spalte von Datumszeit- oder Datetime2-Datentypen partitionieren, da Zeilen mit einem Wert von Mitternacht am selben Tag in derselben Partition wie Zeilen mit späteren Werten 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äteren Tagen in diesem Monat. Dadurch wird bei der Abfrage eines gesamten Tagesdatenwerts eine genaue Partitionsausscheidung unterstützt.

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. Februar 1 ist der erste in der Funktion definierte Begrenzungspunkt, 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 Mindestwert des Datentyps als untere Grenze auf, und die rechtsste Partition weist den maximalen Wert des Datentyps als obere Grenze auf.

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.

Suchen Sie die Beispielsyntax, um Partitionsschemas in CREATE PARTITION SCHEME (Transact-SQL) zu erstellen.

Dateigruppen

Der primäre Grund für das Platzieren ihrer Partitionen in mehreren Dateigruppen besteht darin, sicherzustellen, dass Sie sicherungs- und wiederherstellen-Vorgänge auf Partitionen unabhängig durchführen können. Dies liegt daran, dass Sie Sicherungen für einzelne Dateigruppen ausführen können. Bei Verwendung von tierierten Speicher können Sie mithilfe mehrerer Dateigruppen bestimmte Partitionen bestimmten Speicherebenen zuweisen, z. B. um ältere und weniger häufig zugegriffene Partitionen auf langsameren und weniger kostspieligen 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 eine erhebliche Komplexität zu administrativen Aufgaben im Laufe der Zeit 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 zum 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.

Suchen 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 Partitionierungsspalte:

  • Berechnete Spalten, die an einer Partitionsfunktion teilnehmen, müssen explizit als PERSISTED erstellt werden.
  • Spalten aller Datentypen, die als Indexschlüsselspalten gültig sind, können als Partitionierungsspalte verwendet werden, außer Zeitstempel.
  • Spalten großer Objektdatentypen (LOB) wie z. B. ntext, Text, Bild, xml, varchar(max), nvarchar(max), und varbinary(max), können nicht angegeben werden.
  • Microsoft .NET Framework benutzerdefinierte Typ- und Aliasdatentypspalten können nicht angegeben werden.

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

Beim Erstellen eines nicht gruppierten Indexes wird partition_scheme_name oder Dateigruppe nicht angegeben und die Tabelle wird partitioniert, wird der Index im gleichen Partitionsschema mit derselben Partitionsspalte wie in der zugrunde liegenden Tabelle platziert. Um zu ändern, wie ein vorhandenes Index partitioniert wird, verwenden Sie CREATE INDEX mit der DROP_EXISTING-Klausel. Dadurch 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 in oder aus der Tabelle schnell und effizient wechseln, während die Partitionsstruktur sowohl der Tabelle als auch deren Indizes beibehalten wird. Ein Index muss nicht an derselben benannten Partitionsfunktion teilnehmen, die mit 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 ununique gruppierten Indexes und der Partitionierungsspalte wird nicht explizit im Clusterschlüssel angegeben, fügt das Datenbankmodul standardmäßig die Partitionierungsspalte 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 gruppierten Indexes fügt das Datenbankmodul standardmäßig die Partitionierungsspalte als Nichtschlüsselspalte (eingeschlossen) des Indexs hinzu, um sicherzustellen, dass der Index mit der Basistabelle ausgerichtet ist. Das Datenbankmodul fügt die Partitionierungsspalte nicht zum Index hinzu, wenn er 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 Index, der anders als die entsprechende Tabelle partitioniert wurde. Das heißt, der Index weist ein anderes Partitionsschema auf, das sie 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 Partitionslöschung und verwandte Konzepte in Abfrageverarbeitungsverbesserungen in Partitionentabellen und Indizierungen.

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 in einer partitionierten Tabelle Zeilen über NULLs in der Partitionierungsspalte verfügen, werden diese Zeilen auf der linken seite platziert. Wenn NULL jedoch als erster Grenzwertwert und RANGE RECHTS 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 Speicher, partitionierte Indexvorgänge, DBCC-Befehle und Abfragen. In diesem Abschnitt werden die Leistungsauswirkungen der Verwendung von mehr als 1.000 Partitionen beschrieben und problemumgehungen bei Bedarf bereitgestellt.

Mit bis zu 15.000 Partitionen pro partitionierten Tabelle oder Index können Sie Daten für lange Dauer in einer einzelnen Tabelle speichern. Sie sollten daten jedoch nur so lange beibehalten, wie es erforderlich ist und ein Gleichgewicht zwischen Leistung und Anzahl der Partitionen beibehalten wird.

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 seiner 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 Konfigurieren der Speicherserverkonfigurationsoption für den Index. Für Azure SQL-Datenbank sollten Sie das Ziel des Dienstniveaus 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 die Sortierung zum Erstellen von partitionierten Indizes ausführt, erstellt er 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 sowohl ausgerichtete als auch 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 Umfang des Parallelismus (DOP) größer ist als die Speicheranforderung. Wenn beispielsweise das Datenbankmodul DOP auf 4 festlegt, erfordert ein nicht ausgerichteter Partitionsindex mit 100 Partitionen ausreichend Arbeitsspeicher für vier Prozessoren, um gleichzeitig 4.000 Seiten 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 verringern.

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 die Partitionsausscheidung verwenden, vergleichbare oder verbesserte Leistung mit einer größeren Anzahl von Partitionen haben. 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 wird 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 dauert länger gegen eine partitionierte Tabelle als gegen eine nicht partitionierte Tabelle, wenn das Abfragevorzeichen nicht die Partitionsspalte 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, in 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 die gleiche 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 finden Sie es nützlich, in einigen Abfragen zu verwenden $PARTITION . 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 und zusätzliche bewährte Methoden finden Sie unter Abfrageverarbeitungsverbesserungen 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-Datenbank, Azure SQL Managed Instance und SQL Server 2012 (11.x) und höher werden Statistiken nicht erstellt, indem alle Zeilen in der Tabelle gescannt werden, wenn ein partitioniertes 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 bemerken. 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

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