La différence entre CHAR et VARCHAR dans MySQL

Les

VARCHAR et CHAR susmentionnés sont les deux principaux types de chaînes. Malheureusement, il est difficile d'expliquer exactement comment ces valeurs sont stockées sur le disque et en mémoire, car cela dépend de l'implémentation spécifique du moteur de stockage. La description suivante suppose que le moteur de stockage utilisé est InnoDB et/ou MyISAM. Si vous n'utilisez pas ces deux moteurs de stockage, veuillez vous référer à la documentation du moteur de stockage que vous utilisez.

Regardons d'abord comment les valeurs VARCHAR et CHAR sont généralement stockées sur le disque. Veuillez noter que la façon dont le moteur de stockage stocke les valeurs CHAR ou VARCHAR peut être différente en mémoire que sur le disque, de sorte que les valeurs lues par le serveur MySQL à partir du moteur de stockage devront peut-être être converties dans un autre format de stockage.

Type VARCHAR

Le type VARCHAR est utilisé pour stocker des chaînes de longueur variable et est le type de données de chaîne le plus courant. Il est plus économe en espace que les types de longueur fixe car il utilise uniquement l'espace nécessaire (par exemple, les chaînes plus courtes utilisent moins d'espace). Il existe une exception. Si la table MySQL est créée avec ROW_FORMAT=FIXED, chaque ligne sera stockée avec une longueur fixe, ce qui gaspillera de l'espace.

VARCHAR nécessite 1 ou 2 octets supplémentaires pour enregistrer la longueur de la chaîne : si la longueur maximale de la colonne est inférieure ou égale à 255 octets, seul 1 octet est utilisé pour la représenter, sinon 2 octets sont utilisé. En supposant que le jeu de caractères latin1 soit utilisé, une colonne VARCHAR(10) nécessite 11 octets d'espace de stockage. La colonne VARCHAR(1000) nécessite 1 002 octets car 2 octets sont nécessaires pour stocker les informations de longueur.

VARCHAR économise de l'espace de stockage, il améliore donc également les performances. Cependant, comme la ligne est de longueur variable, elle peut devenir plus longue que l'originale lors de UPDATE, ce qui nécessite un travail supplémentaire. Si l'espace occupé par une ligne augmente et qu'il n'y a plus d'espace à stocker dans la page, différents moteurs de stockage gèrent cette situation différemment. Par exemple, MyISAM divisera les lignes en différents fragments pour le stockage, et InnoDB doit diviser la page afin que les lignes puissent tenir dans la page. Certains autres moteurs de stockage peuvent ne jamais mettre à jour les données dans l'emplacement de données d'origine.

Situations applicables à VARCHAR

Il est approprié d'appliquer VARCHAR dans les situations suivantes :

La longueur maximale de la colonne de chaîne est beaucoup plus grande que la longueur moyenne

Les colonnes sont rarement mises à jour, donc la fragmentation n'est pas un problème

Un jeu de caractères complexe comme UTF-8 est utilisé, chaque caractère est stocké en utilisant un nombre d'octets différent

Type CHAR

Le type CHAR est de longueur fixe : MySQL alloue toujours suffisamment d'espace en fonction de la longueur de chaîne définie. Lors du stockage des valeurs CHAR, MySQL supprime tous les espaces de fin. La valeur CHAR sera complétée par des espaces si nécessaire pour faciliter la comparaison.

CHAR convient au stockage de chaînes très courtes, ou toutes les valeurs sont proches de la même longueur. Par exemple, CHAR est idéal pour stocker la valeur MD5 d'un mot de passe car il s'agit d'une valeur de longueur fixe. Pour les données qui changent fréquemment, CHAR est également meilleur que VARCHAR car le type CHAR de longueur fixe n'est pas sujet à la fragmentation. CHAR est également plus efficace en termes d'espace de stockage que VARCHAR pour les colonnes très courtes. Par exemple, CHAR(1) est utilisé pour stocker uniquement les valeurs Y et N. Si un jeu de caractères sur un seul octet est utilisé, un seul octet est nécessaire, mais VARCHAR(1) nécessite deux octets car il existe un octet supplémentaire pour l'enregistrement. longueur. .

Test

Ce qui suit est un exemple pour illustrer la différence de comportement entre CHAR et VARCHAR Tout d'abord, nous créons une table avec un seul champ CHAR(10), et Insérez-y quelques valeurs :

CREATE TABLE char_test
(
    char_col CHAR(10)
);
 
INSERT INTO char_test 
VALUES
    ('string1').
    ('  string2').
    ('string3  ');

Lorsque nous récupérons ces valeurs, nous constaterons que les espaces à la fin de string3 sont tronqués.

SELECT CONCAT("'", char_col, "'")
FROM char_test;

résultat de l'exécution :

Si vous utilisez le champ VARCHAR(10) pour stocker la même valeur, vous pouvez obtenir le résultat suivant :

CREATE TABLE varchar_test
(
    varchar_col VARCHAR(10)
);
 
INSERT INTO varchar_test 
VALUES
    ('string1').
    ('  string2').
    ('string3  ');
 
SELECT CONCAT("'", varchar_col, "'")
FROM varchar_test;

Résultat d'exécution

La différence entre VARCHAR(5) et VARCHAR(200)

Si nous utilisons VARCHAR(5 ) et VARCHAR(200 ) pour stocker « bonjour », nous savons que la surcharge d'espace des deux est la même. Alors pouvons-nous garder la longueur de VARCHAR toujours grande ? Y a-t-il des avantages à utiliser des colonnes plus courtes ?

Cela s'avère être un gros avantage. Les colonnes plus longues consomment plus de mémoire car MySQL alloue généralement des blocs de mémoire de taille fixe pour contenir les valeurs internes. Ceci est particulièrement problématique lors de l'utilisation de tables temporaires en mémoire pour le tri ou les opérations. C'est tout aussi mauvais lors du tri à l'aide de tables temporaires de disque.

La meilleure stratégie est donc d’allouer uniquement l’espace dont vous avez réellement besoin.

Résumé

Lorsque nous sélectionnons un type pour un champ de type chaîne, pour déterminer s'il faut choisir VARCHAR ou CHAR, nous pouvons considérer les aspects suivants :

Y a-t-il une petite différence entre la longueur moyenne et la longueur maximale de l'ensemble de données du champ ? Si la différence est faible, privilégiez le type CHAR. Sinon, considérez le type VARCHAR.

Si le champ stocke une valeur de hachage après MD5, ou une valeur de longueur fixe, le type CHAR est préféré.

Si le champ doit être mis à jour fréquemment, le type CHAR est prioritaire. Puisque le type CHAR est de longueur fixe, il n'est pas sujet à la fragmentation.

Pour les valeurs de champ qui stockent de très petites informations, telles que le sexe, le type CHAR est préféré, car le type VARCHAR occupera des octets supplémentaires pour stocker les informations sur la longueur de la chaîne.

En un mot, quand on peut choisir le type CHAR, ou quand la consommation d'espace n'est relativement pas au centre des facteurs d'influence, essayez de choisir le type CHAR, car dans d'autres aspects, le type CHAR a plus ou moins d'avantages. Lorsque la consommation d’espace devient un facteur d’influence important, nous envisagerons d’utiliser le type VARCHAR.

Tutoriel recommandé : "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!