Implementierung der Zeilenkomprimierung
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.0 die 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 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 | 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
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter:Einreichen und Feedback anzeigen für