Je optimise des tables innodb dans MySQL, donc j'ai couru Procédure analyse () pour voir quelles étaient les recommandations.
Les résultats recommandés Y a-t-il un gain de performance à être utilisé par l'utilisation de TinyText ? Je ne suis inquiet que de la vitesse ici, pas de taille.
4 Réponses :
Je m'attendrais à ce que Varcharne soit plus rapide que TinyText, et de mon googling autour qui semble être le consensus général. Bien sûr, vous devrez tester votre système pour être vraiment certain.
La raison pour laquelle il est plus rapide, c'est parce que lorsque MySQL effectue certains types d'opérations (jointures, types, etc.), il créera souvent des tables temporaires. Lorsque vous avez un type de blob (tel que TinyText) dans une table temporaire, la table sera basée sur un disque plutôt que sur la mémoire, ce qui aurait bien sûr un impact sur la performance.
J'assumie juste qu'il y aurait un pointeur de blob en mémoire et que l'accès à la blob ne causerait que d'un coup de disque, et seulement pour cette partie de la table?
Vous voudrez peut-être aussi regarder en utilisant Toutefois, REMARQUE: MySQL n'autorisera pas
chez Informit.com/articles/articles.aspx?p=377652&eqnum=3 , j'ai lu que pour les tables d'InnoDb, il est préférable d'utiliser Varcharne: "Le format de stockage de lignes internes ne traite pas les colonnes de longueur fixe et de longueur variable différemment (toutes les lignes utilisent un en-tête contenant des pointeurs sur les valeurs de colonne), Ainsi, en utilisant des colonnes de caractères de longueur fixe n'est pas en soi intrinsèquement plus simple que d'utiliser des colonnes varcharines variables "
intéressant - ne pas contester l'article, c'est juste mon expérience. Bien que j'ai pu utiliser myisam char (255) - alors qu'il utilise plus d'espace, il a été sensiblement plus rapide (dans mon expérience) pour utiliser un champ constant de la taille constante lorsque faire des comparaisons plus tard. L'espace supplémentaire peut être rempli de rembourrage si vous recherchez une vitesse juste, puis ignorez la blancheure plus tard.
varchar et caractères pour exister dans la même table. Cela ne permet pas non plus [généralement] ne permet de comparaisons entre varchar et char . J'ai découvert ceci l'année dernière lors de la mise en œuvre d'une table pour un passe-temps
Char / Varchar va être plus rapide car ces colonnes sont stockées dans la même page que les données de la ligne principale *, tandis que les types de texte sont stockés hors page (j'avais tort, voir commentaire de Harrison ).
Les gens utilisaient beaucoup de TinyText, car Varcharne (ennuyeusement) a trempé. 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).
InnoDB ne stocke pas tous les types de texte hors page. Ce n'est que si une colonne passe au-dessus de 767 octets le stocke hors de la page (c'est-à-dire que certaines lignes peuvent être stockées entièrement en ligne, d'autres stockées à l'extérieur). Étant donné qu'un TinyText ne peut pas obtenir au-dessus de la limite de 767 octets, elle ne sera jamais stockée de la page.
Ne croyez pas si quelqu'un vous dit que TinyText est stocké d'une autre manière que Varchar.
Les différences réelles sont:
TinyText et d'autres champs de texte sont stockés séparément de la rangée en mémoire à l'intérieur de MySQL Heap, tandis que VarcharN () Les champs ajoutent jusqu'à 64k limites (afin que vous puissiez avoir plus de 64k dans des minuscules, alors que vous ne serez pas avec Varchar).
TinyText et d'autres champs "BLOB-like" forceront la couche SQL (MySQL) d'utiliser des tables temporaires sur disque à chaque fois qu'elles sont utilisées, tandis que Varcharner sera toujours trié "en mémoire" (bien que sera convertie en Char pour la pleine largeur).
InnoDB interne ne se soucie pas vraiment de savoir si c'est TinyText ou Varchar. Il est très facile de vérifier, crée deux tables, une avec Varcharate (255), une autre avec Tinyint et insérer un enregistrement aux deux. Ils prendront toutes les deux une seule page de 16k - tandis que si les pages de débordement sont utilisées, la table TinyText doit apparaître comme prenant au moins 32k in 'show Table Status'.
Je préfère généralement Varchar (255) - ils ne causent pas trop de fragmentation de tas pour une rangée unique et peuvent être traités comme un seul objet 64K dans la mémoire à l'intérieur de MySQL. Sur les différences de taille des innodb sont négligeables.