Pour une table innodb dans MySQL, qu'est-ce qui est le plus rapide : varchar(255) ou tinytext ?

Question

Je suis en train d'optimiser certains tables innodb dans MySQL, j'ai donc lancé procédure analsye() pour voir quelles étaient les recommandations.

Les résultats recommandent tinytext au lieu de varchar(255) pour tous les champs qui étaient précédemment configurés en varchar(255)

Existe-t-il un gain de performance à obtenir en utilisant texte minuscule ? Je ne m'intéresse ici qu'à la vitesse, pas à la taille.

Answer 1

Ne croyez pas que quelqu'un vous dise que TINYTEXT est stocké d'une autre manière que VARCHAR.

Les différences réelles sont les suivantes :

• Les champs TINYTEXT et autres TEXT sont stockés séparément de la ligne en mémoire dans le tas de MySQL, alors que les champs VARCHAR() s'ajoutent à la limite de 64k (vous pouvez donc avoir plus de 64k dans les TINYTEXT, alors que vous ne le pouvez pas avec les VARCHAR).

• TINYTEXT et les autres champs de type "blob" obligeront la couche SQL (MySQL) à utiliser des tables temporaires sur disque chaque fois qu'ils seront utilisés, tandis que VARCHAR sera toujours trié "en mémoire" (bien qu'il soit converti en CHAR pour la largeur totale).

• InnoDB ne se préoccupe pas vraiment de savoir s'il s'agit de tinytext ou de varchar. Il est très facile de le vérifier : créez deux tables, l'une avec VARCHAR(255), l'autre avec TINYINT, et insérez un enregistrement dans les deux. Elles prendront toutes deux une seule page de 16k - alors que si des pages de débordement sont utilisées, la table TINYTEXT devrait apparaître comme prenant au moins 32k dans 'SHOW TABLE STATUS'.

Je préfère généralement les VARCHAR(255) - ils ne causent pas trop de fragmentation du tas pour une seule ligne, et peuvent être traités comme un objet unique de 64k dans la mémoire de MySQL. Avec InnoDB, les différences de taille sont négligeables.

Answer 2

Je m'attendrais à ce que varchar soit plus rapide que tinytext, et d'après mes recherches sur Google, cela semble être le consensus général. Bien sûr, il faudrait tester votre système pour en être vraiment certain.

La raison pour laquelle il est plus rapide est que lorsque MySQL effectue certains types d'opérations (jointures, tris, etc.), il crée souvent des tables temporaires. Lorsque vous avez un BLOB (comme tinytext) dans une table temporaire, la table est basée sur le disque plutôt que sur la mémoire, ce qui a bien sûr un impact sur les performances.

Answer 3

CHAR/VARCHAR sera plus rapide car ces colonnes sont stockées dans la même page que les données de la ligne principale*, alors que les types TEXT sont stockés en dehors de la page. (J'avais tort, voir le commentaire de Harrison).

Les gens utilisaient beaucoup tinytext parce que varchar coupait (de manière gênante) les espaces blancs de fin de ligne. Ce comportement a été supprimé dans MySQL 5.0.

(* Au moins pour les 768 premiers octets, et avec InnoDB intégré, pas le nouveau plugin InnoDB ).

Answer 4

Vous pouvez également envisager d'utiliser char(255) - Bien qu'il utilise plus d'espace, il est nettement plus rapide (d'après mon expérience) d'utiliser un champ de taille constante pour effectuer des comparaisons par la suite. L'espace supplémentaire peut être rempli avec du padding si vous recherchez uniquement la rapidité, puis ignorer l'espace blanc par la suite.

Attention toutefois : MySQL n'autorise pas les varchar y char doivent exister dans la même table. Il ne permet pas non plus [en général] de faire des comparaisons entre des varchar y char . Je l'ai découvert l'année dernière en mettant en place une table pour un hobby. projet .