Partitionierte Tabellen und Indizes

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed Instance

SQL Server, Azure SQL-Datenbank und Azure SQL verwaltete Instanz unterstützen Tabellen- und Indexpartitionierung. Die Daten von partitionierten Tabellen und Indizes werden 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 Daten mithilfe des Proportionalfüllalgorithmus auf Dateien verteilt. Die Daten werden horizontal partitioniert, sodass Gruppen von Zeilen einzelnen Partitionen zugeordnet werden. Alle Partitionen eines einzelnen Indexes oder einer Tabelle müssen sich in der gleichen Datenbank befinden. Die Tabelle oder der Index wird als einzelne logische Entität behandelt, wenn Abfragen oder Aktualisierungen für die Daten ausgeführt werden.

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

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

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. Beispielsweise dauert ein Vorgang, z. B. das Laden von Daten aus einem OLTP-System in ein OLAP-System, nur Sekunden anstelle der Minuten und Stunden, die der Vorgang dauert, wenn die Daten nicht partitioniert werden.

• Sie können Standard aufbewahrungs- oder Datenaufbewahrungsvorgänge für eine oder mehrere Partitionen schneller ausführen. Die Vorgänge sind effizienter, da sie auf nur diese Datenteilmengen abzielen, statt auf die ganze Tabelle. Sie können z. B. 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 basierend auf den Arten von Abfragen verbessern, die Sie häufig ausführen. Beispielsweise kann der Abfrageoptimierer Equijoin-Abfragen zwischen zwei oder mehr partitionierten Tabellen schneller verarbeiten, wenn die Partitionierungsspalten mit den Spalten identisch sind, in denen die Tabellen verknüpft sind. 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 einem Satz 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 z. B. eine Tabelle mit Verkaufsauftragsdaten enthalten, können Sie die Tabelle basierend auf einer Datetime-Spalte wie z. B. einem Verkaufsdatum in 12 (monatliche) Partitionen partitionieren.

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

• Ein LINKer 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 wird in einer Partition eingeschlossen.
• Ein RECHTS-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 wird in jeder Partition eingeschlossen.

Wenn "LEFT" oder "RIGHT" nicht angegeben ist, ist der LINK-Bereich die Standardeinstellung.

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

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

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

Für RANGE LEFT und RANGE RIGHT weist die äußerst linke Partition den Minimalwert des Datentyps als untere Grenze auf, und die äußerst rechte Partition hat den Maximalwert des Datentyps als oberer Grenzwert.

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

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 (Transact-SQL).

Dateigruppen

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

Das Verwalten von Dateien und Dateigruppen für partitionierte Tabellen kann im Laufe der Zeit zu administrativen Aufgaben erheblicher Komplexität führen. 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.

Finden Sie Beispielcode zum Erstellen von Dateigruppen für SQL Server und Azure SQL verwaltete Instanz 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.
  • Da nur eine Spalte als Partitionsspalte verwendet werden kann, kann die Verkettung mehrerer Spalten mit einer berechneten Spalte hilfreich sein.
• Spalten aller Datentypen, die für die Verwendung als Indexschlüsselspalten gültig sind, können als Partitionierungsspalte verwendet werden, mit Ausnahme von 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.
• Benutzerdefinierte Datentypspalten und Alias-Datentypspalten für Microsoft .NET Framework (Common Language Runtime, CLR) können nicht angegeben werden.

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

Wenn beim Erstellen eines nicht gruppierten Indexes partition_scheme_name oder Dateigruppe nicht angegeben ist 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 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 ihre Indizes ausgerichtet sind, kann das Datenbankmodul Partitionen schnell und effizient in oder aus der Tabelle wechseln, während Standard die Partitionsstruktur der Tabelle und der 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. 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 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 die Partitionierungsspalte standardmäßig als nicht schlüsselfreie Spalte (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 wurde 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 partitionierten Tabellen und Indizes.

Begrenzungen

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

• Wenn zeilen in einer partitionierten Tabelle NULLs in der Partitionierungsspalte enthalten, werden diese Zeilen auf der linken Partition platziert. Wenn NULL jedoch als erster Grenzwert angegeben wird und RANGE RIGHT in der Partitionsfunktionsdefinition angegeben wird, werden die links meisten Partitionen leer Standard und NULLs 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 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 Standard ein Gleichgewicht zwischen Leistung und Anzahl der Partitionen zu bewahren.

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. 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 16 GB haben, desto geringer ist die Wahrscheinlichkeit, dass Leistungs- und Speicherprobleme auftreten.

Speichereinschrä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 an der Basistabelle ausgerichtet ist oder nicht am gruppierten Index ausgerichtet ist, wenn die Tabelle bereits über einen gruppierten Index verfügt.

In SQL Server und Azure SQL verwaltete Instanz 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 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 ausgerichteter Indizes kann länger dauern, wenn die Anzahl der Partitionen zunimmt. Es wird empfohlen, nicht mehrere Erstellungs- und Neuerstellungs-Indexbefehle gleichzeitig auszuführen, da Leistungs- und Speicherprobleme auftreten können.

Wenn das Datenbankmodul die Sortierung 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 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 der Basistabelle ausgerichtet ist, werden Sortiertabellen nacheinander erstellt, wobei weniger Arbeitsspeicher verwendet wird. Wenn Sie jedoch einen nicht ausgerichteten partitionierten Index erstellen, werden die 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 Speicher nicht verfügbar ist, schlägt der Buildvorgang fehl. Alternativ erfordert ein ausgerichteter partitionierten Index mit 100 Partitionen nur ausreichend Arbeitsspeicher zum Sortieren von 40 Seiten, da die Sortierungen nicht gleichzeitig ausgefü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. Dies liegt daran, dass der Grad der Parallelität (DOP) größer ist als die Speicheranforderung. Wenn das Datenbankmodul beispielsweise DOP auf 4 festlegt, erfordert ein nicht ausgerichteter partitionierten Index 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 der Parallelität manuell zu reduzieren.

DBCC-Befehle

Bei einer größeren Anzahl von Partitionen können DBCC-Befehle wie DBCC CHECKDB und DBCC CHECKTABLE länger ausgeführt werden, da die Anzahl der Partitionen zunimmt.

Abfragen

Nach der Partitionierung einer Tabelle oder eines Indexes können Abfragen, die partitionslöschende Abfragen verwenden, eine vergleichbare oder verbesserte Leistung mit einer größeren Anzahl von Partitionen aufweisen. Abfragen, die keine Partitionslöschung verwenden, können länger dauern, da die Anzahl der Partitionen zunimmt.

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

Wenn Sie häufig Abfragen ausführen, die eine Equijoin zwischen zwei oder mehr partitionierten Tabellen umfassen, sollten ihre Partitionierungsspalten mit den Spalten identisch sein, in 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 gleich sind, in der sie:

• 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 im Verknüpfungsfeld partitioniert werden, kann das Vorhandensein von Partitionen die Abfrageverarbeitung tatsächlich verlangsamen, anstatt sie zu beschleunigen.

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

Weitere Informationen zur Partitionsverarbeitung in der Abfrageverarbeitung, einschließlich paralleler Abfrageausführungsstrategie für partitionierte Tabellen und Indizes und weitere 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-Datenbank, Azure SQL verwaltete Instanz und SQL Server 2012 (11.x) und höher werden Statistiken nicht durch Scannen aller Zeilen in der Tabelle erstellt, wenn ein partitionierter Index erstellt oder neu erstellt wird. Der Abfrageoptimierer generiert stattdessen Statistiken mithilfe des Standardalgorithmus zur Stichprobenentnahme.

Nach dem Upgrade einer Datenbank mit partitionierten Indizes aus einer Version von SQL Server unter 2012 (11.x) stellen Sie möglicherweise einen Unterschied 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.

Zugehöriger Inhalt

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

• Erstellen partitionierter Tabellen und Indizes
• $PARTITION (Transact-SQL)
• Erweitern mit Azure SQL-Datenbank
• Partitionieren von Tabellen im dedizierten SQL-Pool
• Leitfaden zur Architektur und zum Design von SQL Server-Indizes
• 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 Warehouseim SQLCAT-Leitfaden zu: Relational Engineering