Freigeben über

Implementierung von Zeilenkomprimierung

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance

In diesem Artikel wird zusammengefasst, wie Datenbank-Engine 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 werden. Das neue Datensatzspeicherformat bewirkt die folgenden wichtigen Änderungen:

  • Es verringert den mit dem Datensatz verbundenen Metadaten-Overhead. Diese Metadaten umfassen 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 werden für alle Datentypen optimiert und beanspruchen keine Bytes.

Wie Zeilenkomprimierung den Speicherplatz beeinflusst

Die folgende Tabelle beschreibt, wie Zeilenkomprimierung die vorhandenen Typen in SQL Server und Azure SQL-Datenbank beeinflusst. Die Tabelle schließt nicht die Speicherplatzersparnis ein, die mit Seitenkomprimierung erreicht werden kann.

Datentyp Wird der Speicherplatz beeinflusst? Beschreibung
tinyint No 1 Byte ist der minimal benötigte Speicherplatz.
smallint Ja Wenn 1 Byte für den Wert ausreicht, wird nur 1 Byte verwendet.
int Ja Verwendet nur so viele Bytes wie nötig. Wenn ein Wert z. B. in 1 Byte gespeichert werden kann, wird nur 1 Byte Speicherplatz belegt.
bigint Ja Verwendet nur so viele Bytes wie nötig. Wenn ein Wert z. B. in 1 Byte gespeichert werden kann, wird nur 1 Byte Speicherplatz belegt.
decimal Ja Dieser Typ verwendet unabhängig von der angegebenen Genauigkeit nur so viele Bytes wie nötig. Wenn ein Wert z. B. in 3 Bytes gespeichert werden kann, wird nur 3 Bytes Speicherplatz belegt. Der Speicherbedarf stimmt exakt mit dem vardecimal-Speicherformat überein.
numeric Ja Dieser Typ verwendet unabhängig von der angegebenen Genauigkeit nur so viele Bytes wie nötig. Wenn ein Wert z. B. in 3 Bytes gespeichert werden kann, wird nur 3 Bytes Speicherplatz belegt. Der Speicherbedarf stimmt exakt mit dem vardecimal-Speicherformat überein.
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 nachdem alle Stellen nach dem Dezimalkomma entfernt wurden, wird der resultierende ganzzahlige Wert gespeichert. 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 nachdem alle Stellen nach dem Dezimalkomma entfernt wurden, wird der resultierende ganzzahlige Wert gespeichert. Dieser Typ hat einen größeren Bereich als smallmoney. Die Speicheroptimierung dieses Typs ähnelt der für ganzzahlige Typen.
float Ja Geringwertige Bytes mit Nullen werden nicht gespeichert. Diefloat -Komprimierung eignet sich hauptsächlich für nicht gebrochene Werte in Mantissen.
real Ja Geringwertige Bytes mit Nullen werden nicht gespeichert. Diereal -Komprimierung eignet sich hauptsächlich für nicht gebrochene Werte in Mantissen.
smalldatetime No Verwendet die Datendarstellung mit ganzen Zahlen mit 2 Bytes langen ganzen Zahlen und ist die Anzahl der Tage seit 1900-01-01. Für den Datumsteil von smalldatetime gibt es keinen Vorteil durch die smalldatetime.

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

Wenn ein smalldatetime nur für die Darstellung eines Datums verwendet wird (geschieht häufig), ist die Zeit 0.0. 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 von Tagen mit dem Basisdatum 1900-01-01 dar. Die ersten 2 Bytes können die Jahre bis 2079 darstellen. 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 No Verwendet die Datendarstellung mit ganzen Zahlen mit 3 Byte. Dies stellt das Datum ab 0001-01-01 dar. Für heutige Datumsangaben verwendet die Zeilenkomprimierung alle 3 Bytes. Dadurch wird keine Speicherplatzersparnis erreicht.
time No Verwendet die Datendarstellung mit ganzen Zahlen mit 3 - 6 Byte. Es gibt verschiedene Genauigkeiten, die mit 0 bis 9 beginnen, die 3 - 6 Bytes benötigen 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 beim vorherigen Fall wird wahrscheinlich keine Speicherplatzersparnis erreicht.

Genauigkeit = 3. Bytes = 4. Diese Option erreicht geringe Speicherplatzersparnis, da die ersten 3 Bytes bis 5:00 Uhr genommen werden.

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:00 Uhr verwendet.

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

Genauigkeit = 8, Bytes = 6. Das sechste Byte wird nach 3:00 Uhr verwendet.

Bei der Zeilenkomprimierung ändert sich der Speicherplatz nicht. Allgemein ist bei der Komprimierung des time -Datentyps keine große Speicherplatzersparnis zu erwarten.
datetime2 Ja Verwendet die Datendarstellung mit ganzen Zahlen mit 6 - 9 Byte. Die ersten 4 Bytes stellen das Datum dar. Die Anzahl der von der Zeit in Anspruch genommenen Bytes hängt von der Genauigkeit der Zeit ab, die angegeben wird.

Der ganzzahlige Wert stellt die Anzahl von Tagen ab dem 0001-01-01 mit der Obergrenze 31.12.9999 dar. Die Komprimierung nimmt 3 Bytes ein, um ein Datum im Jahr 2005 darzustellen.

Bei der Zeit gibt es keine Speicherplatzersparnis, da hier 2 - 4 Bytes für verschiedene Zeitgenauigkeiten zulässig sind. 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 Ausnahme der vorhandenen 2 Bytes für die Zeitzone mit dem Format (HH:mm).

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

Für Zeitzonenwerte ist der mm-Wert in den meisten Fällen möglicherweise 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 immer dasselbe Auffüllungszeichen ein.
varchar No Keine Auswirkung.
text No Keine Auswirkung.
nchar Ja 1 Nachfolgende Auffüllungszeichen werden entfernt. Die Datenbank-Engine fügt unabhängig von der verwendeten Sortierung immer dasselbe Auffüllungszeichen ein.
nvarchar Nein 1 Keine Auswirkung.
ntext No Keine Auswirkung.
binary Ja Nachfolgende Nullen werden entfernt.
varbinary No Keine Auswirkung.
Abbildung No Keine Auswirkung.
Cursor No Keine Auswirkung.
timestamp / rowversion Ja Verwendet die Datendarstellung mit ganzen Zahlen mit 8 Byte. Es gibt für jede Datenbank einen Zeitstempelzähler, dessen Wert bei 0 beginnt. Dieser Wert kann wie jeder andere ganzzahlige Wert komprimiert werden.
sql_variant No Keine Auswirkung.
uniqueidentifier No Keine Auswirkung.
Tabelle No Keine Auswirkung.
xml Nein2 Keine Auswirkung.
Benutzerdefinierte Typen No Dies wird intern als varbinarydargestellt.
FILESTREAM No Dies wird intern als varbinarydargestellt.

1 Unicode-Komprimierung unterstützt den nchar-Datentyp mit fester Länge und den nvarchar-Datentyp. Datenwerte, die außerhalb von Zeilen oder in nvarchar(max) -Spalten gespeichert werden, werden nicht komprimiert. Unicode-Komprimierung wird nicht für nvarchar(max) -Daten unterstützt, auch wenn sie in Zeile gespeichert wird.

2 Wenn die Datenkomprimierung aktiviert wird, werden Daten außerhalb von Zeilen nicht komprimiert. Beispielsweise verwendet ein XML-Datensatz, der größer als 8.060 Bytes ist, nicht komprimierte Seiten außerhalb der Zeile.

Zugehöriger Inhalt