Partitionierte Tabellen und Indizes

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

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.

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.

• Sie können die Parallelität der Arbeitsauslastung verbessern, indem Sie die Sperreskalation auf Partitionsebene anstelle von Tabellenebene aktivieren. Dies kann Sperrenkonflikte für die Tabelle reduzieren. Um die Sperrkontention zu reduzieren, indem Sie die Sperreskalation auf die Partition zulassen, legen Sie die LOCK_ESCALATION-Option der ALTER TABLE-Anweisung auf AUTO.

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 der Partitionen und die Partitionsgrenzen, ü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 den resultierenden Partitionen platziert werden:

• Ein LEFT Bereich gibt an, dass der Grenzwert zur linken Seite des Begrenzungswertintervalls gehört, wenn Intervallwerte vom Datenbankmodul in aufsteigender Reihenfolge von links nach rechts sortiert werden. Mit anderen Worten, der höchste Begrenzungswert ist in einer Partition enthalten.
• Ein RIGHT Bereich gibt an, dass der Grenzwert zur rechten Seite des Begrenzungswertintervalls gehört, wenn Intervallwerte vom Datenbankmodul in aufsteigender Reihenfolge von links nach rechts sortiert werden. Mit anderen Worten, der niedrigste Begrenzungswert ist in einer Partition enthalten.

Wenn LEFT oder RIGHT nicht angegeben ist, ist der LEFT Bereichstyp der Standard.

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. Es wird ein RIGHT Bereichstyp verwendet, der angibt, dass Grenzwerte in jeder Partition als untere Begrenzungswerte dienen. RIGHT Bereiche sind häufig einfacher zu bearbeiten, wenn eine Tabelle basierend auf einer Spalte der Datentypen "datetime", "datetime2" oder "datetimeoffset " partitioniert wird, da Zeilen mit einem Wert von Mitternacht in derselben Partition wie Zeilen mit den späteren Werten am selben Tag gespeichert werden. Ebenso behält ein Bereich bei Verwendung des Datentyps des RIGHT und der Verwendung von Partitionen eines Monats oder mehr den ersten Tag des Monats in derselben Partition wie spätere Tage in diesem Monat bei. 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 gezeigt, wie eine Tabelle oder ein Index, der diese Partitionsfunktion auf der Partitionierungsspalte datecol verwendet, partitioniert wird. Der 1. Februar ist der erste in der Funktion definierte Grenzpunkt. Da ein RIGHT Bereichstyp verwendet wird, ist der 1. Februar die untere Grenze der Partition 2.

Für sowohl RANGE LEFT als auch RANGE RIGHT hat die äußerste linke Partition den Minimalwert des Datentyps als untere Grenze, und die äußerste rechte Partition hat den Maximalwert des Datentyps als obere Grenze.

Weitere Beispiele für Partitionsfunktionen mit den LEFT Typen und RIGHT Bereichstypen finden Sie unter 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.

Filegroups

Es gibt zwei Gründe, ein Partitionsschema mit mehreren Dateigruppen zu verwenden:

• 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.
• Sie können jede Dateigruppe unabhängig sichern und wiederherstellen. Dies bedeutet, dass Sie wiederholte Sicherungen von Partitionen überspringen können, die nicht geändert werden, oder die Wiederherstellungszeit verkürzen, wenn nur die Daten in einigen Partitionen wiederhergestellt werden müssen.

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 Sicherungs- und Wiederherstellungsprozeduren nicht von der Verwendung mehrerer Dateigruppen profitieren und wenn Sie keinen mehrstufigen Speicher verwenden, 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.

Weitere Informationen zum Erstellen von Dateigruppen in SQL Server und azure SQL Managed Instance finden Sie unter ALTER DATABASE (Transact-SQL) Datei- und Dateigruppenoptionen.

Spaltspaltungsspalte

Die Spalte einer Tabelle oder eines Indexes, die die Eingabe einer Partitionsfunktion ist. Bei der Auswahl einer Partitioning-Spalte sind die folgenden Überlegungen anzustellen:

• Berechnete Spalten, die an einer Partitionsfunktion teilnehmen, müssen explizit als PERSISTEDerstellt werden.
  • Da nur eine Spalte als Partitionierungsspalte verwendet werden kann, kann die Verkettung mehrerer Spalten in einer berechneten Spalte hilfreich 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 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.
• Spalten mit benutzerdefinierten CLR-Datentypen und Alias-Datentypen können nicht angegeben werden.

Um eine Tabelle oder einen Index zu partitionieren, geben Sie das Partitionsschema und die Partitionierungsspalte in den CREATE TABLE-, ALTER TABLE- und CREATE INDEX-Anweisungen an.

Wenn beim Erstellen eines nicht gruppierten Indexes ein Partitionsschema oder eine Dateigruppe nicht angegeben wird und die Tabelle partitioniert wird, wird der Index im selben Partitionsschema mit derselben Partitionsspalte wie die zugrunde liegende Tabelle platziert. Verwenden Sie CREATE INDEX mit der DROP_EXISTING Klausel, um zu ändern, wie ein vorhandener Index partitioniert wird. 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 demselben Partitionsschema wie die entsprechende Tabelle basiert, wird als ausgerichteter Index bezeichnet. Wenn eine Tabelle und ihre nicht gruppierten Indizes ausgerichtet sind, kann das Datenbankmodul Partitionen in oder aus der Tabelle schnell und effizient wechseln und gleichzeitig die Partitionsstruktur der Tabelle und ihrer Indizes beibehalten. Ein Index muss nicht in derselben Partitionsfunktion enthalten sein, um mit seiner 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 gruppierten Index partitionieren und die Partitionierungsspalte nicht explizit im Clusterschlüssel angegeben ist, fügt das Datenbankmodul die Partitionierungsspalte standardmäßig der Liste der gruppierten Indexschlüssel hinzu. Wenn der gruppierte Index eindeutig ist, müssen Sie die Partitionierungsspalte explizit zum gruppierten Indexschlüssel hinzufügen. 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 verwendet eine Partitionsfunktion mit einer anderen Definition von Partitionsgrenzen oder eine andere Partitionierungsspalte. Das Erstellen eines nicht ausgerichteten partitionierten Indexes kann in den folgenden Fällen hilfreich sein:

• Die Basistabelle ist nicht partitioniert.
• Der Indexschlüssel ist eindeutig, enthält nicht die Partitionierungsspalte der Tabelle, und die Eindeutigkeit des Indexes muss beibehalten werden.
• Sie möchten lokalisierte Verknüpfungen zwischen einer Tabelle und mehreren anderen Tabellen verwenden, die unterschiedlich partitioniert sind.

Partitionseliminierung

Wenn das Abfrage-Prädikat auf die Partitionierungsspalte verweist, kann das Datenbankmodul einige Partitionen beim Lesen einer partitionierten Tabelle oder eines Indexes möglicherweise beseitigen oder überspringen. Dies kann die Abfrageleistung verbessern.

Erfahren Sie mehr über die Beseitigung von Partitionen und verwandte Konzepte in Erweiterungen der Abfrageverarbeitung bei partitionierten Tabellen und Indizes.

Limitations

• 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 Dienstebenen von Azure SQL-Datenbank, SQL-Datenbank in Fabric und azure SQL Managed Instance verfügbar.

  • In Azure SQL-Datenbank und SQL-Datenbank in Fabric müssen alle Partitionen in der PRIMARY Dateigruppe platziert werden, da nur die PRIMARY Dateigruppe bereitgestellt wird.

• Die Tabellenpartitionierung ist in dedizierten SQL-Pools in Azure Synapse Analytics mit einigen Syntaxunterschieden verfügbar. Erfahren Sie mehr unter Partitioning von Tabellen in dedizierten SQL Pools.

• 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. Partitionsfunktionen und Partitionsschemas gehören nicht zu einem Schema.

• Wenn Zeilen in einer partitionierten Tabelle NULLs in der Partitioning-Spalte enthalten, werden diese Zeilen in der Partition ganz links platziert. Wenn NULL jedoch als erster Grenzwert RANGE RIGHT angegeben und in der Partitionsfunktionsdefinition angegeben wird, bleibt die linksste Partition leer, und NULLs werden in der zweiten Partition platziert.

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

Leistungsrichtlinien

Die Datenbank-Engine unterstützt bis zu 15.000 Partitionen pro Tabelle oder Index. Die Verwendung einer großen Anzahl von Partitionen hat jedoch Auswirkungen auf Speicher, partitionierte Indexvorgänge, DBCC-Befehle, Schemaänderung und Abfrageleistung. In diesem Abschnitt werden die Leistungsauswirkungen von Designs beschrieben, die eine große Anzahl von Partitionen umfassen und bei Bedarf Problemumgehungen bieten.

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. Dies ist insbesondere der Fall, wenn der Index nicht an der Basistabelle ausgerichtet ist oder nicht an seinem gruppierten Index ausgerichtet ist.

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.

Bei Azure SQL-Datenbank sollten Sie die Berechnungsgröße der Datenbank vorübergehend oder dauerhaft erhöhen, um mehr Arbeitsspeicher zu erhalten.

Vorgänge für partitionierte Indizes

Das Erstellen und Neuerstellen nicht ausgerichteter Indizes in einer Tabelle mit mehr als 1.000 Partitionen ist möglicherweise 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 SORT_IN_TEMPDB-Indexoption 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, ist der Buildvorgang erfolgreich, die Leistung kann jedoch beeinträchtigt werden. Wenn dieser Speicher nicht verfügbar ist, schlägt der Buildvorgang 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.

Bei ausgerichteten und nicht ausgerichteten Indizes kann die Speicheranforderung größer sein, wenn das Datenbankmodul die Abfrageparallelität im Indexbuildvorgang verwendet. Je größer der Grad der Parallelität (DOP), desto höher ist die Speicheranforderung. 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 den Grad der Parallelität als Problemumgehung zu reduzieren, auf Kosten einer potenziell längeren Indexbuildzeit.

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.

Queries

Nach der Partitionierung einer Tabelle oder eines Indexes können Abfragen, die Partition-Eliminierung verwenden, 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.

Angenommen, eine Tabelle enthält 100 Millionen Zeilen und Spalten A und B.

• 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 in der Tabelle, die eine WHERE Klauselfilterung für Die Spalte A enthält, führt eine Partitionslöschung durch und scannt eine Teilmenge aller Partitionen. 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 TOP, MAX oder MIN auf Spalten verwenden, die nicht die Partitionierungsspalte sind, können unter Leistungseinbußen bei der Partitionierung leiden, 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.

Auf diese Weise kann der Abfrageoptimierer die Verknüpfung schneller verarbeiten, da die Verknüpfung Daten aus Paaren verbundener Partitionen verarbeitet. 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 unter $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.

Statistische Berechnung während partitionierten Indexvorgängen

Wenn ein nicht partitionierter Index erstellt oder neu erstellt wird, erstellt das Datenbankmodul auch Statistiken zum Index, indem alle Zeilen im Index überprüft werden. Wenn jedoch ein partitionierter Index erstellt oder neu erstellt wird, werden Statistiken mit dem Standard-Samplingalgorithmus erstellt.

Wenn Sie Statistiken zu partitionierten Indizes erstellen oder aktualisieren möchten, indem Sie eine größere Stichprobe oder alle Zeilen in der Tabelle überprüfen, verwenden Sie CREATE STATISTICS oder UPDATE STATISTICS mit den Klauseln SAMPLE oder FULLSCAN.

Verwandte Inhalte

• Erstellen partitionierter Tabellen und Indizes
• $PARTITION (Transact-SQL)
• Skalieren mit Azure SQL-Datenbank
• Partitionierungstabellen im dedizierten SQL-Pool
• Indexarchitektur- und -Entwurfsleitfaden
• Partitionierte Tabellen- und Indexstrategien für SQL Server 2008
• So implementieren Sie ein automatisch gleitendes Fenster
• Massenladen in eine partitionierte Tabelle
• Verbesserte Abfrageverarbeitung bei partitionierten Tabellen und Indizes
• Top 10 Best Practices zum Erstellen eines relationalen Data Warehouses mit großem Maßstab