web-dev-qa-db-fra.com

Longueur de la colonne varchar - y a-t-il un avantage à utiliser 255?

Je rencontre souvent des colonnes qui sont varchar(255), donc c'est probablement une convention de toutes sortes. 255 est 2 ^ 8 - 1. Y a-t-il donc quelque chose de "magique" dans les longueurs qui sont 2 ^ n - 1? Ou tout simplement 255? Existe-t-il un avantage d'optimisation des performances ou du stockage pour certaines longueurs varchar spécifiques? Ou est-ce juste une vieille sagesse qui ne s'applique plus aux versions actuelles de MariaDB et MySQL?

mysqlmariadb
5
dbdemon

Je pique contre 255 de temps en temps. Bien sûr, il y a anciennement quelques raisons pour '255', mais beaucoup ne sont plus valides, et même contre-productives.

Dans MySQL, il y a des raisons de s'arrêter à 191, 255, 767, 64K et probablement d'autres valeurs. Certains dépendent du moteur, d'autres de CHARACTER SET, Etc.

Un VARCHAR est stocké sous la forme d'une longueur de 1 ou 2 octets plus suffisamment d'octets pour le texte actuel dans le jeu de caractères que vous avez spécifié. Cependant, le choix de 1 ou 2 est pas entraîné uniquement par la colonne individuelle; il est déterminé par la taille totale des lignes. Autrement dit, ce n'est pas une excuse valable pour utiliser 255.

Utilisez une longueur qui est

  • Assez grand pour ne jamais être dépassé de façon conservatrice
  • Aussi petit que cela semble raisonnable.

Pendant que je me déchaîne ... CHAR (fixed length) est rarement conseillé. Et presque toujours, il devrait être CHARACTER SET ascii - country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 et UUID devraient être poussés plus loin, mais c'est une autre diatribe .)

Impacts négatifs potentiels de l'utilisation aveugle de "255":

  • Si vous avez lot de colonnes, vous pouvez atteindre une limite de taille de ligne maximale et CREATE TABLE Échouera.
  • Vous pourriez dépasser une limite de taille d'index.
  • Complexe SELECTs peut avoir besoin d'une table temporaire et peut utiliser MEMORY pour cela. Dans ce cas, VARCHAR(255) devient CHAR(255) pour la table temporaire. Et, si vous utilisez utf8, cela représente 755 octets pour chaque ligne! (8.0 corrige ce défaut de conception?)

Connexes: n'utilisez pas aveuglément BIGINT pour tous les nombres. Cela prend 8 octets. Même INT est excessif, à 4 octets. Voir MEDIUMINT, SMALLINT et TINYINT. Sachez que (2) Sur INT(2) ne veut rien dire; cela prend encore 4 octets.

6
Rick James

À un moment donné, c'était la longueur maximale d'une colonne dans Sybase et le serveur SQL dérivé. Je suis sûr que d'autres l'ont copié pour maintenir la compatibilité afin que la migration des applications/SQL vers une nouvelle plate-forme ne soit pas difficile, car tout le monde se battait pour gagner des parts de marché à l'époque.

Il n'y a pas vraiment de bonne raison de le perpétuer, à part la compatibilité. J'ai remarqué qu'il semble avoir été remplacé par varchar (max) ces jours-ci.

3
Mike

Des longueurs de colonne "standard" sont utilisées partout et indiquent invariablement qu'aucun effort n'a été fait pour comprendre la longueur réelle requise de la colonne.

Si vous avez une colonne où il n'y aura jamais plus de 24 caractères utilisés, pourquoi spécifier la longueur de la colonne à 255?

L'analyse et l'utilisation de la longueur correcte pour les colonnes de longueur variable nécessitent un petit effort et garantissent que les effets secondaires de l'utilisation d'une longueur de colonne trop grande ne deviennent jamais un problème. Je sais que votre question concerne MySQL, cependant cette réponse montre comment SQL Server utilise les longueurs de colonne de diverses manières qui peuvent ne pas être apparentes au premier abord.

2
Max Vernon