Qu'est-ce que le format de stockage de lignes InnoDB-tutoriel mysql-php.cn

Dans les versions antérieures d'InnoDB, comme il n'y avait qu'un seul format de fichier, il n'était pas nécessaire de nommer ce format de fichier. À mesure que le moteur InnoDB évolue, de nouveaux formats de fichiers incompatibles avec les versions antérieures sont développés pour prendre en charge de nouvelles fonctionnalités. Aujourd'hui, nous allons présenter le format de stockage de lignes InnoDB.

Qu'est-ce que le format de stockage de lignes InnoDB

Le moteur de stockage InnoDB prend en charge quatre formats : REDONDANT, COMPACT, DYNAMIQUE et COMPRESSÉ.

Présentation du format de ligne InnoDB

Quest-ce que le format de stockage de lignes InnoDB

Format de ligne REDUNDANT

Le format REDUNDANT offre une compatibilité avec les anciennes versions de MySQL.

Le format de ligne REDUNDANT est pris en charge par deux formats de fichiers InnoDB (Antelope et Barracuda).

Les tables utilisant le format de ligne REDONDANT stockent les 768 premiers octets de valeurs de colonne de longueur variable (types VARCHAR, VARBINARY, BLOB et TEXT) dans des enregistrements d'index au sein des nœuds B-tree et le reste sur des pages de débordement. Les colonnes de longueur fixe supérieures ou égales à 768 octets sont codées sous forme de colonnes de longueur variable et peuvent être stockées hors page. Par exemple, une colonne CHAR(255) peut dépasser 768 octets si la longueur maximale en octets du jeu de caractères est supérieure à 3 utf8mb4.

Si la valeur de la colonne est de 768 octets ou moins, les pages de débordement ne sont pas utilisées et peuvent entraîner des économies d'E/S puisque la valeur est entièrement stockée dans le nœud B-tree. Cela fonctionne bien pour les valeurs de colonne BLOB relativement courtes, mais peut entraîner le remplissage des nœuds B-tree avec des données plutôt que des valeurs clés, ce qui les rend moins efficaces. Les tables avec de nombreuses colonnes BLOB peuvent rendre les nœuds B-tree trop pleins et contenir trop peu de lignes, ce qui rend l'index entier moins efficace que si les lignes étaient plus courtes ou si les valeurs des colonnes étaient stockées hors page.

Fonctionnalités de stockage au format de ligne REDONDANT

Le format de ligne REDONDANT possède les fonctionnalités de stockage suivantes :

Chaque enregistrement d'index contient un en-tête de 6 octets. Les en-têtes sont utilisés pour relier des enregistrements consécutifs entre eux et pour le verrouillage au niveau des lignes.
Les enregistrements dans un index clusterisé contiennent des champs pour toutes les colonnes définies par l'utilisateur. De plus, il existe un champ d'ID de transaction de 6 octets et un champ de pointeur roulant de 7 octets.
Si aucune clé primaire n'est définie pour la table, chaque enregistrement d'index cluster contient également un champ d'ID de ligne de 6 octets.
Chaque enregistrement d'index secondaire contient toutes les colonnes de clé primaire définies pour la clé d'index clusterisé qui ne figurent pas dans l'index secondaire.
Les enregistrements contiennent des pointeurs vers chaque champ de l'enregistrement. Si la longueur totale des champs de l'enregistrement est inférieure à 128 octets, le pointeur est d'un octet, sinon de deux octets. Le tableau de pointeurs est appelé répertoire d'enregistrement. La zone pointée par le pointeur est la partie données de l'enregistrement.
En interne, les colonnes de caractères de longueur fixe telles que CHAR(10) sont stockées dans un format de longueur fixe. Les espaces de fin ne sont pas tronqués dans les colonnes VARCHAR. Les colonnes de longueur fixe supérieures ou égales à 768 octets sont codées sous forme de colonnes de longueur variable et peuvent être stockées hors page. Par exemple, une colonne CHAR(255) peut dépasser 768 octets si la longueur maximale en octets du jeu de caractères est supérieure à 3 utf8mb4.
Les valeurs SQL NULL conservent un ou deux octets dans le répertoire d'enregistrement. Les valeurs NULL SQL conserveront zéro octet dans la partie données de l'enregistrement si elles sont stockées dans une colonne de longueur variable. Pour les colonnes de longueur fixe, la longueur fixe de la colonne est conservée dans la partie données de l'enregistrement. La réservation d'un espace fixe pour les valeurs NULL permet aux colonnes d'être mises à jour de NULL vers des valeurs non NULL sans provoquer de fragmentation de la page d'index.

Format de ligne COMPACT

Par rapport au format de ligne REDONDANT, le format de ligne COMPACT réduit l'espace de stockage des lignes d'environ 20 %, REDONDANT se fait au prix d'une utilisation accrue du processeur pour certaines opérations. Si votre charge de travail est typique et limitée par le taux de réussite du cache et la vitesse du disque, le format COMPACT peut être plus rapide. Si la charge de travail est limitée par la vitesse du processeur, le format compact peut être plus lent.

Le format de ligne COMPACT est pris en charge par deux formats de fichiers InnoDB (Antelope et Barracuda).

Les tables utilisant le format de ligne COMPACT stockent les 768 premiers octets de valeurs de colonne de longueur variable (types VARCHAR, VARBINARY et BLOB et TEXT) dans des enregistrements d'index au sein des nœuds B-tree et le reste sur des pages de débordement.

Les colonnes de longueur fixe supérieures ou égales à 768 octets sont codées sous forme de colonnes de longueur variable et peuvent être stockées hors page. Par exemple, CHAR(255) si la longueur maximale en octets du jeu de caractères est supérieure à 3, peut dépasser 768 octets si la colonne est un type de caractères utf8mb4.

Fonction de stockage au format de ligne COMPACT

Le format de ligne COMPACT présente les caractéristiques de stockage suivantes :

Chaque enregistrement d'index contient un en-tête de 5 octets, qui peut être précédé d'un en-tête de longueur variable. Les en-têtes sont utilisés pour relier des enregistrements consécutifs entre eux et pour le verrouillage au niveau des lignes.
La partie de longueur variable de l'en-tête d'enregistrement contient un vecteur de bits indiquant une colonne NULL. Si le nombre de colonnes dans l'index peut être NULL , le vecteur binaire occupe N octets. (Par exemple, s'il peut y avoir entre 9 et 16 colonnes, le vecteur de bits utilise deux octets.) Colonnes qui n'occupent pas d'espace au-delà des bits de ce vecteur. La partie de longueur variable de l'en-tête contient également la longueur de la colonne de longueur variable. Chaque longueur nécessite un ou deux octets, en fonction de la longueur maximale de la colonne. Si toutes les colonnes de l'index sont CEILING(*N*/8)NULLNULLNOT NULL et ont une longueur fixe, l'en-tête de l'enregistrement n'a pas de partie de longueur variable.
Pour chaque champ de longueur variable non NULL, l'en-tête d'enregistrement contient un ou deux octets de la longueur de la colonne. Seuls deux octets sont requis si une partie de la colonne est stockée en dehors de la page de débordement, ou si la longueur maximale dépasse 255 octets et la longueur réelle dépasse 127 octets. Pour les colonnes de stockage externe, la longueur de 2 octets représente la longueur de la section de stockage interne plus un pointeur de 20 octets vers la section de stockage externe. La partie interne fait 768 octets, donc la longueur est de 768 + 20. Le pointeur de 20 octets stocke la vraie longueur de la colonne.
L'en-tête de l'enregistrement est suivi du contenu des données de la colonne non NULL.
Les enregistrements dans un index clusterisé contiennent des champs pour toutes les colonnes définies par l'utilisateur. De plus, il existe un champ d'ID de transaction de 6 octets et un champ de pointeur roulant de 7 octets.
Si aucune clé primaire n'est définie pour la table, chaque enregistrement d'index cluster contient également un champ d'ID de ligne de 6 octets.
Chaque enregistrement d'index secondaire contient toutes les colonnes de clé primaire définies pour la clé d'index clusterisé qui ne figurent pas dans l'index secondaire. Si des colonnes de clé primaire sont de longueur variable, l'en-tête d'enregistrement de chaque index secondaire comporte une section de longueur variable pour enregistrer leur longueur, même si les index secondaires sont définis sur des colonnes de longueur fixe.
En interne, pour les jeux de caractères de longueur non variable, colonnes de caractères de longueur fixe (par exemple stockées au format de longueur fixe CHAR(10). Les espaces de fin ne sont pas tronqués dans les colonnes VARCHAR.
En interne, pour les jeux de caractères de longueur variable tels que utf8mb3 et utf8mb4, InnoDB tente de stocker les octets en supprimant les espaces de fin. Si la valeur de la colonne dépasse le nombre d'octets, les espaces de fin sont ajustés à la longueur minimale de la valeur de la colonne en octets. La longueur maximale d'une colonne est la longueur maximale d'octets de caractères × CHAR(*N*)NCHAR(*N*)NCHAR(*N*)

N avec le nombre minimum d'octets réservés. Dans de nombreux cas, réserver un espace minimum permet d'effectuer les mises à jour des colonnes sans provoquer de fragmentation des pages d'index. En revanche, lors de l'utilisation du format de ligne, les colonnes occupent une longueur maximale d'octets de caractères × CHAR(*N*)NCHAR(*N*)NREDUNDANT

Les colonnes de longueur fixe supérieures ou égales à 768 octets sont codées en longueur variable. Les champs peuvent être stockés hors page. Par exemple, CHAR(255) si la longueur maximale en octets du jeu de caractères est supérieure à 3, peut dépasser 768 octets si la colonne est un type de caractères utf8mb4.行Diagramme des caractéristiques de stockage du format de ligne compact

Structure du format de compatibilité Mysql Innodb

En fait, InnoDB ajoutera trois colonnes cachées à chaque donnée, ce qui sont

Quest-ce que le format de stockage de lignes InnoDB

DYNAMIC row format

COMPACT format de ligne qui fournit le même format de caractéristiques de stockage, mais ajoute des capacités de stockage améliorées pour les longues colonnes de longueur variable et prend en charge les préfixes pour les grandes clés d'index. Quest-ce que le format de stockage de lignes InnoDB

Le format de fichier Barracuda prend en charge le format de ligne DYNAMIQUE.

Créez une table lorsque vous utilisez ROW_FORMAT=DYNAMIC, InnoDB peut stocker de longues valeurs de colonne de longueur variable (pour les types VARCHAR, VARBINARY, BLOB et TEXT) complètement hors page, et l'enregistrement d'index clusterisé ne contient qu'un pointeur de 20 octets vers la page de débordement . Les champs de longueur fixe supérieurs ou égaux à 768 octets sont codés sous forme de champs de longueur variable. Par exemple, CHAR(255) si la longueur maximale en octets du jeu de caractères est supérieure à 3, peut dépasser 768 octets si la colonne est un type de caractères utf8mb4.

Le fait qu'une colonne soit stockée hors page dépend de la taille de la page et de la taille totale des lignes. Lorsqu'une ligne est trop longue, la colonne la plus longue est sélectionnée pour le stockage hors page jusqu'à ce que l'enregistrement d'index clusterisé tienne sur une page B-tree. TEXT et BLOB sont des colonnes inférieures ou égales à 40 octets stockées sur la ligne.

Le format de ligne DYNAMIQUE maintient l'efficacité du stockage de la ligne entière dans le nœud d'index où elle correspond (comme le font les formats COMPACT et REDUNDANT), mais le format de ligne DYNAMIQUE évite le problème du remplissage des nœuds B-tree avec un grand nombre d'octets de données de colonnes longues. Le format de ligne DYNAMIQUE est basé sur l'idée que si une partie d'une valeur de données longue est stockée hors de la page, il est généralement plus efficace de stocker la valeur entière hors de la page. Pour le format DYNAMIQUE, des colonnes plus courtes peuvent être conservées dans les nœuds B-tree, minimisant ainsi le nombre de pages de débordement requises pour une ligne donnée.

Le format de ligne DYNAMIQUE prend en charge les préfixes de clé d'index jusqu'à 3072 octets. Cette fonctionnalité est contrôlée par la variable innodb_large_prefix, qui est activée par défaut. Pour plus d'informations sur innodb_large_prefix, consultez la description de la variable.

Les tables utilisant le format de ligne DYNAMIQUE peuvent être stockées dans des espaces de table système, des espaces de table fichier par table et des espaces de table généraux. Pour stocker DYNAMIC une table dans l'espace table système, désactivez innodb_file_per_table et utilisez une instruction CREATE TABLE ou ALTER TABLE normale, ou utilisez l'option de table TABLESPACE [=] innodb_system avec CREATE TABLE ou ALTER TABLE. Les variables innodb_file_per_table et innodb_file_format ne s'appliquent pas aux espaces de table généraux et ne sont pas non plus applicables lorsque l'option de table TABLESPACE [=] innodb_system est utilisée pour stocker des tables DYNAMIC dans l'espace de table système.

Fonctionnalités de stockage au format de ligne DYNAMIQUE

Le format de ligne DYNAMIQUE est un écart par rapport au format de ligne COMPACT.

FORMAT DE LIGNE COMPRESSÉ

FORMAT DE LIGNE COMPRESSÉ fournit les mêmes caractéristiques et fonctionnalités de stockage que le FORMAT DE LIGNE DYNAMIQUE, mais ajoute la prise en charge de la compression des données de table et d'index.

Le format de fichier Barracuda prend en charge le format de ligne COMPRESSÉ.

Le format de ligne COMPRESSÉ utilise un stockage hors page de détails internes similaire à celui du format de ligne DYNAMIQUE, où les considérations de stockage et de performances supplémentaires des données de table et d'index sont compressées et utilisent des tailles de page plus petites. À l'aide du format de ligne COMPRESSED, l'option KEY_BLOCK_SIZE contrôle la quantité de données de colonne stockée dans l'index clusterisé et la quantité placée sur la page de débordement.

Le format de ligne COMPRESSÉ prend en charge les préfixes de clé d'index jusqu'à 3072 octets. Cette fonctionnalité est contrôlée par la variable innodb_large_prefix, qui est activée par défaut.

COMPRESSED peut créer des tables dans un espace de table fichier ou un espace de table général par table en utilisant le format de ligne. L'espace table système ne prend pas en charge le format de ligne COMPRESSÉ. Pour stocker des tables COMPRESSÉES dans un espace table fichier par table, la variable innodb_file_per_table doit être activée et innodb_file_format doit être définie sur Barracuda. Les variables innodb_file_per_table et innodb_file_format ne s'appliquent pas aux espaces table généraux. Les espaces table généraux prennent en charge tous les formats de ligne, mais il convient de noter qu'en raison des différentes tailles de page physiques, les tableaux compressés et non compressés ne peuvent pas coexister dans le même espace table général. Voir Section 14.6.3.3, « Tablespaces généraux » pour plus d'informations.

Fonction de stockage au format de ligne COMPRESSÉ

Le format de ligne COMPRESSÉ est un écart par rapport au format de ligne COMPACT. C'est juste qu'il y a une petite différence lors du traitement des données de débordement de ligne. Les 768 premiers octets de la chaîne ne seront pas stockés dans les données réelles de l'enregistrement. Au lieu de cela, tous les octets seront stockés dans d'autres pages, uniquement dans les données réelles de. l'enregistrement. Les adresses des autres pages sont stockées ici. De plus, le format de ligne compressé utilisera un algorithme de compression pour compresser la page.

Recommandations associées : "Tutoriel mysql"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!