Implementierung der Zeilenkomprimierung

  • Artikel

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

In diesem Artikel wird zusammengefasst, wie Datenbank-Engine die Zeilenkomprimierung implementiert. Diese Zusammenfassung enthält grundlegende Informationen, die Ihnen bei der Planung des Speicherplatzes helfen, den Sie für Ihre Daten benötigten.

Durch die Aktivierung der Komprimierung wird nur das physische Speicherformat der Daten eines bestimmten Datentyps geändert, jedoch nicht deren Syntax oder Semantik. Anwendungsänderungen sind nicht erforderlich, wenn eine oder mehrere Tabellen für die Komprimierung aktiviert sind. Das neue Datensatzspeicherformat bewirkt die folgenden wichtigen Änderungen:

  • Es verringert den mit dem Datensatz verbundenen Metadaten-Overhead. Diese Metadaten sind Informationen zu Spalten, deren Längen und Offsets. In einigen Fällen ist der Metadaten-Overhead möglicherweise größer als das alte Speicherformat.

  • Es verwendet ein Speicherformat variabler Länge für numerische Datentypen (z.B. integer, decimalund float) und die Datentypen, die auf numerischen Werten basieren (z.B. datetime und money).

  • Es speichert feste Zeichenfolgen in einem Format variabler Länge, ohne die Leerzeichen zu speichern.

Hinweis

NULL und 0 Werte in allen Datentypen sind optimiert und nehmen keine Bytes in Anspruch.

Auswirkungen der Zeilenkomprimierung auf den Speicher

In der folgenden Tabelle wird beschrieben, wie sich die Zeilenkomprimierung auf die vorhandenen Typen in SQL Server und Azure SQL-Datenbank auswirkt. Die Tabelle enthält nicht die Einsparungen, die mithilfe der Seitenkomprimierung erzielt werden können.

Datentyp Wird der Speicherplatz beeinflusst? Beschreibung
tinyint Nein 1 Byte ist der minimal benötigte Speicherplatz.
smallint Ja Wenn der Wert in 1 Byte passt, wird nur ein Byte verwendet.
int Ja Verwendet nur so viele Bytes wie nötig. Wenn beispielsweise ein Wert in 1 Byte gespeichert werden kann, dauert der Speicher nur 1 Byte.
bigint Ja Verwendet nur so viele Bytes wie nötig. Wenn beispielsweise ein Wert in 1 Byte gespeichert werden kann, dauert der Speicher nur 1 Byte.
decimal Ja Dieser Typ verwendet unabhängig von der angegebenen Genauigkeit nur so viele Bytes wie nötig. Wenn beispielsweise ein Wert in 3 Byte gespeichert werden kann, dauert der Speicher nur 3 Byte. Der Speicherbedarf entspricht genau dem Vardecimal-Speicherformat .
numeric Ja Dieser Typ verwendet unabhängig von der angegebenen Genauigkeit nur so viele Bytes wie nötig. Wenn beispielsweise ein Wert in 3 Byte gespeichert werden kann, dauert der Speicher nur 3 Byte. Der Speicherbedarf entspricht genau dem Vardecimal-Speicherformat .
bit Ja Der Metadaten-Overhead benötigt 4 Bits.
smallmoney Ja Verwendet die Datendarstellung mit ganzen Zahlen mit einer 4 Bytes langen ganzen Zahl. Der Währungswert wird mit 10.000 multipliziert, und der resultierende ganzzahlige Wert wird gespeichert, indem alle Ziffern nach dem Dezimalkomma entfernt werden. Die Speicheroptimierung dieses Typs ähnelt der für ganzzahlige Typen.
money Ja Verwendet die Datendarstellung mit ganzen Zahlen mit einer 8 Bytes langen ganzen Zahl. Der Währungswert wird mit 10.000 multipliziert, und der resultierende ganzzahlige Wert wird gespeichert, indem alle Ziffern nach dem Dezimalkomma entfernt werden. Dieser Typ hat einen größeren Bereich als smallmoney. Die Speicheroptimierung dieses Typs ähnelt der für ganzzahlige Typen.
float Ja Am wenigsten signifikante Bytes mit Nullen werden nicht gespeichert. Diefloat -Komprimierung eignet sich hauptsächlich für nicht gebrochene Werte in Mantissen.
real Ja Am wenigsten signifikante Bytes mit Nullen werden nicht gespeichert. Diereal -Komprimierung eignet sich hauptsächlich für nicht gebrochene Werte in Mantissen.
smalldatetime Nein Verwendet die ganzzahlige Datendarstellung mithilfe von zwei 2-Byte-Ganzzahlen und ist die Anzahl der Tage seit 1900-01-01. Es gibt keinen Vorteil der Zeilenkomprimierung für den Datumsteil von smalldatetime.

Die Zeit ist die Anzahl von Minuten seit Mitternacht. Zeitwerte, die geringfügig nach 4:00 Uhr liegen, verwenden das zweite Byte.

Wenn eine smalldatetime nur verwendet wird, um ein Datum (ein gängiger Fall) darzustellen, lautet 0.0die Uhrzeit . Mit der Komprimierung werden 2 Bytes gespart, indem die Zeit im höchstwertigen Byteformat für Zeilenkomprimierung gespeichert wird.
datetime Ja Verwendet die Datendarstellung mit ganzen Zahlen mit 4 Bytes langen ganzen Zahlen. Der ganzzahlige Wert stellt die Anzahl der Tage mit dem Basisdatum von 1900-01-01. Die ersten 2 Bytes können bis zum Jahr 2079darstellen. Mit der Komprimierung können hier bis zu diesem Punkt immer 2 Bytes gespart werden. Jeder ganzzahlige Wert stellt 3,33 Millisekunden dar. Die Komprimierung schöpft die ersten 2 Bytes in den ersten fünf Minuten aus und benötigt das vierte Byte nach 16:00 Uhr. Deshalb wird mit der Komprimierung nach 16:00 Uhr nur 1 Byte gespart. Wenn datetime wie jede andere ganze Zahl komprimiert wird, werden mit der Komprimierung 2 Bytes beim Datum gespart.
date Nein Verwendet die Datendarstellung mit ganzen Zahlen mit 3 Byte. Dies stellt das Datum von 0001-01-01. Für heutige Datumsangaben verwendet die Zeilenkomprimierung alle 3 Bytes. Dadurch wird keine Speicherplatzersparnis erreicht.
time Nein Verwendet die ganzzahlige Datendarstellung mithilfe von 3 bis 6 Byte. Es gibt verschiedene Genauigkeiten, die mit 0 bis 9 beginnen, die 3 bis 6 Byte dauern können. Komprimierter Speicherplatz wird folgendermaßen verwendet:

Genauigkeit = 0. Bytes = 3. Jeder ganzzahlige Wert stellt eine Sekunde dar. Die Komprimierung kann mit 2 Bytes Zeit bis 18:00 Uhr darstellen, wodurch potenziell 1 Byte gespart wird.

Genauigkeit = 1. Bytes = 3. Jeder ganzzahlige Wert stellt 1/10 Sekunde dar. Die Komprimierung verwendet das dritte Byte vor 2:00 Uhr. Resultiert in einer geringen Speicherplatzersparnis.

Genauigkeit = 2. Bytes = 3. Ähnlich wie im vorherigen Fall ist es unwahrscheinlich, einsparungen zu erzielen.

Genauigkeit = 3. Bytes = 4. Da die ersten 3 Byte von 5AM eingenommen werden, erzielt diese Option wenig Einsparungen.

Genauigkeit = 4. Bytes = 4. Die ersten 3 Bytes werden in den ersten 27 Sekunden genommen. Es wird keine Speicherplatzersparnis erwartet.

Genauigkeit = 5, Bytes = 5. Das fünfte Byte wird nach 12-Mittag verwendet.

Genauigkeit = 6 und 7, Bytes = 5. Es wird keine Speicherplatzersparnis erreicht.

Genauigkeit = 8, Bytes = 6. Das sechste Byte wird nach 3AM verwendet.

Es gibt keine Änderung des Speichers für die Zeilenkomprimierung. Allgemein ist bei der Komprimierung des time -Datentyps keine große Speicherplatzersparnis zu erwarten.
datetime2 Ja Verwendet die ganzzahlige Datendarstellung mithilfe von 6 bis 9 Byte. Die ersten 4 Bytes stellen das Datum dar. Die von der Zeit eingenommenen Bytes hängen von der Genauigkeit der angegebenen Zeit ab.

Der ganzzahlige Wert stellt die Anzahl der Tage seit 0001-01-01 einer oberen Grenze von 12.31.9999 dar. Um ein Datum im Jahr 2005 darzustellen, dauert die Komprimierung 3 Byte.

Es gibt keine Zeitersparnis, da sie 2 bis 4 Byte für verschiedene Zeitgenauigkeiten zulässt. Deshalb verwendet die Komprimierung für eine Zeitgenauigkeit von einer Sekunde 2 Bytes für die Zeit, wobei das zweite Byte nach 255 Sekunden genommen wird.
datetimeoffset Ja Ähnelt "datetime2", mit der Ausnahme, dass es 2 Byte Zeitzone des Formats (HH:mm) gibt.

Wie bei datetime2können mit der Komprimierung 2 Bytes gespart werden.

Bei Zeitzonenwerten kann der mm Wert für die meisten Fälle gelten 0 . Deshalb kann mit der Komprimierung möglicherweise 1 Byte gespart werden.

Bei der Zeilenkomprimierung ändert sich der Speicherplatz nicht.
char Ja Nachfolgende Auffüllungszeichen werden entfernt. Die Datenbank-Engine fügt unabhängig von der verwendeten Sortierung dasselbe Abstandszeichen ein.
varchar Nein Keine Auswirkung.
text Nein Keine Auswirkung.
nchar Ja 1 Nachfolgende Auffüllungszeichen werden entfernt. Die Datenbank-Engine fügt unabhängig von der verwendeten Sortierung dasselbe Abstandszeichen ein.
nvarchar Nein 1 Keine Auswirkung.
ntext Nein Keine Auswirkung.
binary Ja Nachfolgende Nullen werden entfernt.
varbinary Nein Keine Auswirkung.
Abbildung Nein Keine Auswirkung.
Cursor Nein Keine Auswirkung.
timestamp / rowversion Ja Verwendet die Datendarstellung mit ganzen Zahlen mit 8 Byte. Es gibt einen Zeitstempelzähler, der für jede Datenbank Standard enthält, und der Wert beginnt mit 0. Dieser Wert kann wie jeder andere ganzzahlige Wert komprimiert werden.
sql_variant Nein Keine Auswirkung.
uniqueidentifier Nein Keine Auswirkung.
table Nein Keine Auswirkung.
xml Nein2 Keine Auswirkung.
Benutzerdefinierte Typen Nein Dies wird intern als varbinarydargestellt.
FILESTREAM Nein Dies wird intern als varbinarydargestellt.

1 Unicode-Komprimierung unterstützt die Datentypen "nchar " und "nvarchar ". Datenwerte, die außerhalb der Zeile oder in nvarchar(max)-Spalten gespeichert sind, werden nicht komprimiert. Die Unicode-Komprimierung wird für nvarchar(max) -Daten nicht unterstützt, auch wenn sie in Zeile gespeichert ist.

2 Off-Row-Daten werden beim Aktivieren der Datenkomprimierung nicht komprimiert. Ein XML-Eintrag, der größer als 8.060 Byte ist, verwendet beispielsweise Nichtzeilenseiten, die nicht komprimiert werden.

Zugehöriger Inhalt