Analyser la méthode MySQL de modification dynamique de la longueur de varchar

Bien que cette situation ne devrait pas se produire, généralement comme notre base de données relationnelle, nous aurions dû la concevoir à l'avance et ne pouvons pas la modifier plus tard, mais en raison de la négligence du travail précédent , en fait, pour être honnête, ce n'est pas seulement ma négligence personnelle, c'est principalement dû à des raisons de communication. Bien sûr, j'ai conçu la base de données après tout, donc je dois encore me critiquer.

Parlons de la situation : le champ MySQL a un champ de valeur varchar trop court, 30 sont définis, (je me souviens vaguement que varchar est extensible, bien sûr la réalité ne me tolère pas vaguement), je n'ai donc pu trouver qu'un moyen de modifier dynamiquement la longueur du champ varchar tout en m'assurant que les données de la base de données restaient inchangées. Après avoir cherché pendant un moment, je l'ai finalement trouvé.

alter table 表名 modify column 字段名 varchar(数量);

Cette fonction est assez puissante, mais je rappelle quand même à tout le monde qu'il est préférable d'éviter ce genre de problème lors de la conception.

PS : Le problème de la définition de la longueur de varchar dans MySQL

Si un certain élément est défini sur varchar(50)

alors bien sûr, c'est pour l'anglais 50

Et le chinois ?

Le chinois UTF-8 occupe 3 octets

Alors, ce varchar(50) ne peut-il stocker que 16 caractères chinois

mysql varchar(50) Indépendamment du chinois ou de l'anglais, 50 sont stockés

document MySQL5, qui décrit le type de champ varchar comme suit : varchar(m) longueur variable chaîne . M représente la longueur maximale de la colonne. La plage de M va de 0 à 65 535. (La longueur réelle maximale d'un VARCHAR est déterminée par la taille de la ligne la plus longue et le jeu de caractères utilisé ; la longueur effective maximale est de 65 532 octets).

Pourquoi ça a changé comme ça ? J'ai vraiment l'impression que le manuel de MySQL est trop peu convivial, car il faut lire attentivement pour trouver cette description : MySQL 5.1 est conforme à la spécification SQL standard et ne supprime pas les espaces de fin des valeurs VARCHAR. VARCHAR est enregistré avec un préfixe long d'un ou deux octets + données. Si la longueur déclarée d'une colonne VARCHAR est supérieure à 255, le préfixe de longueur est de deux octets.

D'accord, il me semble comprendre un peu. Mais plus précisément, il a dit que lorsque la longueur est supérieure à 255, un préfixe de longueur de 2 octets est utilisé. Problème de soustraction à l'école primaire : 65535 - 2 = 65533. Je ne sais pas comment ces experts l’ont calculé, donc je garde mes doutes pour l’instant ?

Remarque : j'ai testé en utilisant l'encodage UTF8 et la longueur maximale de varchar est de 21 854 octets.

Testé sous mysql version 5.0.45 et encodage de base de données utf8 : la définition varchar la plus longue est 21785. En d’autres termes, qu’il s’agisse de lettres, de chiffres ou de caractères chinois, seuls 21 785 peuvent être placés.

Conjecture : le nombre maximum d'octets varchar est de 65535, et utf8 code un caractère avec 3 octets 65535/3=21785.

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!