Da es in früheren InnoDB-Versionen nur ein Dateiformat gab, war es nicht nötig, dieses Dateiformat zu benennen. Während sich die InnoDB-Engine weiterentwickelt, werden neue Dateiformate entwickelt, die mit früheren Versionen nicht kompatibel sind, um neue Funktionen zu unterstützen. Heute stellen wir das InnoDB-Zeilenspeicherformat vor.
InnoDB-Speicher-Engine unterstützt vier Formate: REDUNDANT, KOMPAKT, DYNAMISCH und KOMPRIMIERT.
Übersicht über das InnoDB-Zeilenformat
REDUNDANT-Zeilenformat
Das REDUNDANT-Format bietet Kompatibilität mit älteren Versionen von MySQL.
Das REDUNDANT-Zeilenformat wird von zwei InnoDB-Dateiformaten (Antelope und Barracuda) unterstützt.
Tabellen im REDUNDANT-Zeilenformat speichern die ersten 768 Bytes von Spaltenwerten variabler Länge (VARCHAR-, VARBINARY-, BLOB- und TEXT-Typen) in Indexdatensätzen innerhalb von B-Tree-Knoten und den Rest auf Überlaufseiten. Spalten mit fester Länge größer oder gleich 768 Byte werden als Spalten mit variabler Länge codiert und können außerhalb der Seite gespeichert werden. Beispielsweise kann eine CHAR(255)-Spalte 768 Byte überschreiten, wenn die maximale Bytelänge des Zeichensatzes größer als 3 utf8mb4 ist.
Wenn der Wert der Spalte 768 Byte oder weniger beträgt, werden Überlaufseiten nicht verwendet und können zu einigen E/A-Einsparungen führen, da der Wert vollständig im B-Tree-Knoten gespeichert wird. Dies funktioniert gut für relativ kurze BLOB-Spaltenwerte, kann jedoch dazu führen, dass B-Tree-Knoten mit Daten statt mit Schlüsselwerten gefüllt werden, was sie weniger effizient macht. Tabellen mit vielen BLOB-Spalten können dazu führen, dass B-Tree-Knoten zu voll werden und zu wenige Zeilen enthalten, wodurch der gesamte Index weniger effizient ist, als wenn die Zeilen kürzer wären oder die Spaltenwerte außerhalb der Seite gespeichert würden.
Speicherfunktionen für das REDUNDANT-Zeilenformat
Das REDUNDANT-Zeilenformat verfügt über die folgenden Speicherfunktionen:
Jeder Indexdatensatz enthält einen 6-Byte-Header. Header werden zum Verknüpfen aufeinanderfolgender Datensätze und zum Sperren auf Zeilenebene verwendet.
Datensätze in einem Clustered-Index enthalten Felder für alle benutzerdefinierten Spalten. Darüber hinaus gibt es ein 6-Byte-Transaktions-ID-Feld und ein 7-Byte-Rolling-Pointer-Feld.
Wenn für die Tabelle kein Primärschlüssel definiert ist, enthält jeder Clustered-Index-Datensatz auch ein 6-Byte-Zeilen-ID-Feld.
Jeder Sekundärindexdatensatz enthält alle Primärschlüsselspalten, die für den Clustered-Indexschlüssel definiert sind und nicht im Sekundärindex enthalten sind.
Datensätze enthalten Zeiger auf jedes Feld des Datensatzes. Wenn die Gesamtlänge der Felder im Datensatz weniger als 128 Byte beträgt, beträgt der Zeiger ein Byte, andernfalls zwei Byte. Das Array von Zeigern wird als Datensatzverzeichnis bezeichnet. Der Bereich, auf den der Zeiger zeigt, ist der Datenteil des Datensatzes.
Intern werden Zeichenspalten fester Länge wie CHAR(10) im Format fester Länge gespeichert. Nachgestellte Leerzeichen werden aus VARCHAR-Spalten nicht abgeschnitten. Spalten mit fester Länge größer oder gleich 768 Byte werden als Spalten mit variabler Länge codiert und können außerhalb der Seite gespeichert werden. Beispielsweise kann eine CHAR(255)-Spalte 768 Byte überschreiten, wenn die maximale Bytelänge des Zeichensatzes größer als 3 utf8mb4 ist.
SQL-NULL-Werte behalten ein oder zwei Bytes im Datensatzverzeichnis. NULL-SQL-Werte behalten null Bytes im Datenteil des Datensatzes bei, wenn sie in einer Spalte mit variabler Länge gespeichert werden. Bei Spalten mit fester Länge wird die feste Länge der Spalte im Datenteil des Datensatzes beibehalten. Durch die Reservierung von festem Speicherplatz für NULL-Werte können Spalten von NULL- auf Nicht-NULL-Werte aktualisiert werden, ohne dass es zu einer Fragmentierung der Indexseite kommt.
COMPACT-Zeilenformat
Im Vergleich zum REDUNDANT-Zeilenformat reduziert das COMPACT-Zeilenformat den Zeilenspeicherplatz um etwa 20 %, REDUNDANT geht jedoch mit einer erhöhten CPU-Auslastung für bestimmte Vorgänge einher. Wenn Ihre Arbeitslast typisch ist und durch die Cache-Trefferquote und die Festplattengeschwindigkeit begrenzt ist, ist das COMPACT-Format möglicherweise schneller. Wenn die Arbeitslast durch die CPU-Geschwindigkeit begrenzt ist, ist das kompakte Format möglicherweise langsamer.
Das COMPACT-Zeilenformat wird von zwei InnoDB-Dateiformaten (Antelope und Barracuda) unterstützt.
Tabellen im COMPACT-Zeilenformat speichern die ersten 768 Bytes von Spaltenwerten variabler Länge (VARCHAR-, VARBINARY- und BLOB- und TEXT-Typen) in Indexdatensätzen innerhalb von B-Tree-Knoten und den Rest auf Überlaufseiten.
Spalten fester Länge größer oder gleich 768 Byte werden als Spalten variabler Länge codiert und können außerhalb der Seite gespeichert werden. Beispielsweise kann CHAR(255), wenn die maximale Bytelänge des Zeichensatzes größer als 3 ist, 768 Byte überschreiten, wenn die Spalte vom Zeichentyp utf8mb4 ist.
Wenn der Wert der Spalte 768 Byte oder weniger beträgt, werden Überlaufseiten nicht verwendet und können zu einigen Einsparungen bei der E/A führen, da der Wert vollständig im B-Tree-Knoten gespeichert wird. Dies funktioniert gut für relativ kurze BLOB-Spaltenwerte, kann jedoch dazu führen, dass B-Tree-Knoten mit Daten statt mit Schlüsselwerten gefüllt werden, was sie weniger effizient macht. Tabellen mit vielen BLOB-Spalten können dazu führen, dass B-Tree-Knoten zu voll werden und zu wenige Zeilen enthalten, wodurch der gesamte Index weniger effizient ist, als wenn die Zeilen kürzer wären oder die Spaltenwerte außerhalb der Seite gespeichert würden.
Kompakte Zeilenformat-Speicherfunktion
Das kompakte Zeilenformat weist die folgenden Speichereigenschaften auf:
Jeder Indexdatensatz enthält einen 5-Byte-Header, dem ein Header variabler Länge vorangestellt werden kann. Header werden zum Verknüpfen aufeinanderfolgender Datensätze und zum Sperren auf Zeilenebene verwendet.
Der Abschnitt mit variabler Länge des Datensatzheaders enthält einen Bitvektor, der eine NULL-Spalte angibt. Wenn die Anzahl der Spalten im Index NULL sein kann, belegt der Bitvektor N Bytes. (Wenn beispielsweise zwischen 9 und 16 Spalten vorhanden sein können, verwendet der Bitvektor zwei Bytes.) Spalten, die keinen Platz über den Bits in diesem Vektor hinaus belegen. Der Teil der Kopfzeile mit variabler Länge enthält auch die Länge der Spalte mit variabler Länge. Jede Länge erfordert ein oder zwei Bytes, abhängig von der maximalen Länge der Spalte. Wenn alle Spalten im Index CEILING(*N*/8)NULLNULLNOT NULL sind und eine feste Länge haben, hat der Datensatzkopf keinen Teil mit variabler Länge.
Für jedes Feld mit variabler Länge ungleich NULL enthält der Datensatzkopf ein oder zwei Bytes der Spaltenlänge. Es sind nur zwei Bytes erforderlich, wenn ein Teil der Spalte außerhalb der Überlaufseite gespeichert wird oder wenn die maximale Länge 255 Bytes und die tatsächliche Länge 127 Bytes überschreitet. Bei externen Speicherspalten stellt die 2-Byte-Länge die Länge des internen Speicherabschnitts plus einen 20-Byte-Zeiger auf den externen Speicherabschnitt dar. Der innere Teil ist 768 Bytes groß, die Länge beträgt also 768 + 20. Der 20-Byte-Zeiger speichert die wahre Länge der Spalte.
Auf den Datensatzkopf folgt der Dateninhalt der Nicht-NULL-Spalte.
Datensätze in einem Clustered-Index enthalten Felder für alle benutzerdefinierten Spalten. Darüber hinaus gibt es ein 6-Byte-Transaktions-ID-Feld und ein 7-Byte-Rolling-Pointer-Feld.
Wenn für die Tabelle kein Primärschlüssel definiert ist, enthält jeder Clustered-Index-Datensatz auch ein 6-Byte-Zeilen-ID-Feld.
Jeder Sekundärindexdatensatz enthält alle Primärschlüsselspalten, die für den Clustered-Indexschlüssel definiert sind und nicht im Sekundärindex enthalten sind. Wenn Primärschlüsselspalten eine variable Länge haben, verfügt der Datensatzheader jedes Sekundärindex über einen Abschnitt mit variabler Länge, um ihre Länge aufzuzeichnen, selbst wenn Sekundärindizes für Spalten mit fester Länge definiert sind.
Intern für Zeichensätze mit nicht variabler Länge, Zeichenspalten mit fester Länge (z. B. im CHAR(10)-Format mit fester Länge gespeichert). Nachgestellte Leerzeichen werden aus VARCHAR-Spalten nicht abgeschnitten.
Intern versucht InnoDB für Zeichensätze variabler Länge wie utf8mb3 und utf8mb4, Bytes zu speichern, indem es nachgestellte Leerzeichen kürzt. Wenn der Spaltenwert mehr als Bytes beträgt, werden nachfolgende Leerzeichen an die Mindestlänge des Spaltenwerts in Bytes angepasst. Die maximale Länge einer Spalte ist die maximale Zeichenbytelänge × CHAR(*N*)NCHAR(*N*)NCHAR(*N*)
N mit der minimalen Anzahl reservierter Bytes. Durch die Reservierung von minimalem Speicherplatz können Spaltenaktualisierungen in vielen Fällen abgeschlossen werden, ohne dass es zu einer Fragmentierung der Indexseite kommt. Im Gegensatz dazu belegen Spalten bei Verwendung des Zeilenformats eine maximale Zeichenbytelänge × CHAR(*N*)NCHAR(*N*)NREDUNDANT
Spalten mit fester Länge größer oder gleich 768 Bytes werden als Felder mit variabler Länge codiert, die gespeichert werden können Offpage. Beispielsweise kann CHAR(255), wenn die maximale Bytelänge des Zeichensatzes größer als 3 ist, 768 Byte überschreiten, wenn die Spalte vom Zeichentyp utf8mb4 ist.行Speicherfunktionen für das kompakte Zeilenformat
|. Name | (Bit) |. Beschreibung |. —————————— |. Unbekannt | |. Ob der Datensatz 1 | ist im Index-Heap | 
DYNAMISCHES Zeilenformat
KOMPAKTES Zeilenformat vorliegen, das das gleiche Speichercharakteristikformat bietet, aber erweiterte Speicherfunktionen für hinzufügt lange Spalten variabler Länge und unterstützt Präfixe für große Indexschlüssel. Das Barracuda-Dateiformat unterstützt das DYNAMIC-Zeilenformat.
Erstellen Sie eine Tabelle, wenn Sie ROW_FORMAT = DYNAMIC verwenden. InnoDB kann lange Spaltenwerte variabler Länge (für die Typen VARCHAR, VARBINARY, BLOB und TEXT) vollständig außerhalb der Seite speichern und der Clustered-Index-Datensatz enthält nur einen 20-Byte-Zeiger auf die Überlaufseite. Felder mit fester Länge größer oder gleich 768 Byte werden als Felder mit variabler Länge codiert. Beispielsweise kann CHAR(255), wenn die maximale Bytelänge des Zeichensatzes größer als 3 ist, 768 Byte überschreiten, wenn die Spalte vom Zeichentyp utf8mb4 ist.
Ob eine Spalte außerhalb der Seite gespeichert wird, hängt von der Seitengröße und der Gesamtgröße der Zeilen ab. Wenn eine Zeile zu lang ist, wird die längste Spalte für die Off-Page-Speicherung ausgewählt, bis der Clustered-Index-Datensatz auf eine B-Tree-Seite passt. TEXT und BLOB sind Spalten kleiner oder gleich 40 Bytes, die in der Zeile gespeichert werden.
Das DYNAMIC-Zeilenformat behält die Effizienz bei, eine ganze Zeile in einem Indexknoten zu speichern, wenn sie passt (wie es bei den Formaten COMPACT und REDUNDANT der Fall ist), aber das DYNAMIC-Zeilenformat vermeidet das Problem, B-Tree-Knoten mit einer großen Zahl zu füllen von langen Spaltendatenbytes. Das DYNAMIC-Zeilenformat basiert auf der Idee, dass es normalerweise am effizientesten ist, den gesamten Wert außerhalb der Seite zu speichern, wenn ein Teil eines langen Datenwerts außerhalb der Seite gespeichert wird. Beim DYNAMIC-Format können kürzere Spalten in B-Tree-Knoten beibehalten werden, wodurch die Anzahl der für eine bestimmte Zeile erforderlichen Überlaufseiten minimiert wird.
Das dynamische Zeilenformat unterstützt Indexschlüsselpräfixe mit bis zu 3072 Byte. Diese Funktion wird durch die Variable innodb_large_prefix gesteuert, die standardmäßig aktiviert ist. Weitere Informationen zu innodb_large_prefix finden Sie in der Variablenbeschreibung.
Tabellen im DYNAMIC-Zeilenformat können in System-Tablespaces, Datei-pro-Tabellen-Tablespaces und allgemeinen Tablespaces gespeichert werden. Um eine Tabelle DYNAMISCH im Systemtabellenbereich zu speichern, deaktivieren Sie innodb_file_per_table und verwenden Sie eine reguläre CREATE TABLE- oder ALTER TABLE-Anweisung oder verwenden Sie die Tabellenoption TABLESPACE [=] innodb_system mit CREATE TABLE oder ALTER TABLE. Die Variablen innodb_file_per_table und innodb_file_format gelten nicht für allgemeine Tablespaces und sind auch nicht anwendbar, wenn die Tabellenoption TABLESPACE [=] innodb_system zum Speichern von DYNAMIC-Tabellen im System-Tablespace verwendet wird.
DYNAMISCHE Zeilenformat-Speicherfunktionen
Das DYNAMISCHE Zeilenformat ist eine Abweichung vom COMPACT-Zeilenformat.
COMPRESSED ROW FORMAT
COMPRESSED ROW FORMAT bietet die gleichen Speichermerkmale und Funktionen wie das DYNAMIC ROW FORMAT, fügt jedoch Unterstützung für die Komprimierung von Tabellen- und Indexdaten hinzu.
Das Barracuda-Dateiformat unterstützt das KOMPRIMIERTE Zeilenformat.
Das KOMPRIMIERTE Zeilenformat verwendet ähnliche interne Details außerhalb der Seitenspeicherung wie das DYNAMISCHE Zeilenformat, bei dem zusätzliche Speicher- und Leistungsaspekte aus Tabellen- und Indexdaten komprimiert werden und kleinere Seitengrößen verwenden. Bei Verwendung des Zeilenformats COMPRESSED steuert die Option KEY_BLOCK_SIZE, wie viele Spaltendaten im Clustered-Index gespeichert werden und wie viele auf der Überlaufseite platziert werden.
Das komprimierte Zeilenformat unterstützt Indexschlüsselpräfixe mit bis zu 3072 Byte. Diese Funktion wird durch die Variable innodb_large_prefix gesteuert, die standardmäßig aktiviert ist.
COMPRESSED kann Tabellen in einem Datei-Tablespace oder einem allgemeinen Tablespace pro Tabelle im Zeilenformat erstellen. Der Systemtabellenbereich unterstützt das COMPRESSED-Zeilenformat nicht. Um KOMPRIMIERTE Tabellen in einem Datei-pro-Tabelle-Tablespace zu speichern, muss die Variable innodb_file_per_table aktiviert und innodb_file_format auf Barracuda gesetzt sein. Die Variablen innodb_file_per_table und innodb_file_format gelten nicht für allgemeine Tabellenbereiche. Allgemeine Tabellenbereiche unterstützen alle Zeilenformate. Es ist jedoch zu beachten, dass komprimierte und unkomprimierte Tabellen aufgrund unterschiedlicher physischer Seitengrößen nicht gleichzeitig im selben allgemeinen Tabellenbereich vorhanden sein können. Weitere Informationen finden Sie in Abschnitt 14.6.3.3, „Allgemeine Tablespaces“.
Speicherfunktion für das komprimierte Zeilenformat
Das komprimierte Zeilenformat ist eine Abweichung vom kompakten Zeilenformat. Es gibt lediglich einen kleinen Unterschied beim Umgang mit Zeilenüberlaufdaten. Die ersten 768 Bytes der Zeichenfolge werden nicht in den realen Daten des Datensatzes gespeichert. Stattdessen werden alle Bytes auf anderen Seiten gespeichert, sondern nur in den realen Daten Die Adressen anderer Seiten werden hier gespeichert. Darüber hinaus verwendet das komprimierte Zeilenformat einen Komprimierungsalgorithmus, um die Seite zu komprimieren.
Verwandte Empfehlungen: „MySQL-Tutorial“
Das obige ist der detaillierte Inhalt vonWas ist das InnoDB-Zeilenspeicherformat?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
