n'importe quel point de repère, graphique quelque chose du tout? C'est tous les académiques et théoriques sur le Web. p>
OK, ce n'est pas la première fois que cette question a été posée, ils disent tous que l'utilisation des résultats de Char est plus rapide? J'ai même lu dans les livres de MySQL, c'est tout de même, mais je n'ai pas rencontré de référence qui prouve cela. P>
Quelqu'un peut-il verser une lumière sur ceci? P>
4 Réponses :
Je suppose que vous devriez ramasser le gant et le faire. P>
C'est une logique simple, de simplifier, je vais prendre l'exemple d'un fichier CSV ... P>
serait-il plus rapide de chercher dans cette ligne p>
1231; 231; 32345; 21312; 23435552; 1231; 1; 243; 211; 3525321; 44343112; P>
ou celui-ci p>
12; 23; 43; 54; 56; 76; 54; 83; 45; 91; 28; 92 P>
Tant que vous définissez votre longueur correctement, vous devez être plus rapide car le format prédéfini aide le temps de traitement. P>
Donc, si ce que vous dites est vrai, il n'ya pas d'augmentation de vitesse réelle d'utiliser de l'utilisation de caractères à moins que, par exemple, une colonne «FULLNAME NOM (20)» contient tous les noms complets remplis exactement de données pertinentes à 20 caractères. Droit? Ou cela se produit automatiquement car l'espace mort est ajouté en tant que sentier sur ces colonnes?
L'espace est ajouté - il y a donc toujours exactement exactement 20. C'est pourquoi il est plus rapide.
Notez que cela ne s'applique que si tous les champs de la ligne sont une largeur fixe.
Pour rendre l'exemple précis lorsque vous avez des chaînes de longueur variable, vous devriez représenter beaucoup de caractères vides pour le char. Dans ce cas, le Varchar est en réalité plus facile à lire.
Nous avons encore une merveilleuse contradiction :) "Dans quel cas, le Varchar est plus facile à lire."
Le point est, ce n'est pas le cas. Pas par lui-même quand même. P>
Qu'est-ce qui est vrai cependant, c'est que s'il existe des champs Il pourrait y avoir une différence pour des champs très courts. Si vous comparez Char (1) VS Varchar (1), ce dernier prend deux fois plus de mémoire que le premier (en codages à un octet unique) P>
Char sera plus rapide car il est longueur fixe. Par exemple CHAR (10) et VARCHAR (10) Char (10) est une chaîne de longueur fixe de 10 tandis que Varcharate est une chaîne de longueur variable avec une longueur maximale de 10.
Char (10) strong> P> {Index} (Length) [String]
-------------------------
{0} (10) [AAAAAAAA ]
{1} (10) [BBBBB ]
{2} (10) [CCC ]
{3} (10) [DDDDDDD ]
{4} (10) [EE ]
{5} (10) [FFFF ]
Ce n'est pas le cas, à moins que vous n'ayez des chaînes de longueur fixes, alors que le char est plus rapide.
Pas d'attente, alors par nature Char ne peut pas avoir une longueur de piqûre variable, car le repos est une partie de la chaîne seulement que son espace blanc, je ne pense pas que la partie "à moins que" s'applique ici comme étant déjà corrigée. -