Par les documents MySQL il existe quatre types de TEXTE :
- TINYTEXT
- TEXTE
- MEDIUMTEXT
- LONGTEXT
Quelle est la longueur maximale que je peux stocker dans une colonne de chaque type de données en supposant que le codage des caractères est UTF-8 ?
Par les documents MySQL il existe quatre types de TEXTE :
Quelle est la longueur maximale que je peux stocker dans une colonne de chaque type de données en supposant que le codage des caractères est UTF-8 ?
De la documentation (MySQL 8) :
Type | Maximum length
-----------+-------------------------------------
TINYTEXT | 255 (2 8−1) bytes
TEXT | 65,535 (216−1) bytes = 64 KiB
MEDIUMTEXT | 16,777,215 (224−1) bytes = 16 MiB
LONGTEXT | 4,294,967,295 (232−1) bytes = 4 GiB
Notez que le nombre de caractères qui peuvent être stockés dans votre colonne dépendront de la codage des caractères .
@Bridge Je ne suis pas sûr de comprendre, mais cela signifie que le TINYTEXT peut atteindre 255 caractères, n'est-ce pas ???
@Lykos Oui, en fonction des personnages. Extrait de la documentation : A TEXT column with a maximum length of 255 (28 – 1) characters. The effective maximum length is less if the value contains multi-byte characters.
Voir la réponse d'Ankan pour plus de détails.
@aurel.g C'est ainsi que vous répondez réellement à la question. Et je suis d'accord avec Christophe, c'est ainsi que mySQL devrait présenter ses paramètres - même si ce n'est que comme un raccourci supplémentaire à leur... obscure vue de texte.
Expansion de la même réponse
IL S'AGIT D'UN TABLEAU D'ESTIMATION APPROXIMATIF POUR DES DÉCISIONS RAPIDES !
x-x
Type | A= worst case (x/3) | B = best case (x) | words estimate (A/4.5) - (B/4.5)
-----------+---------------------------------------------------------------------------
TINYTEXT | 85 | 255 | 18 - 56
TEXT | 21,845 | 65,535 | 4,854.44 - 14,563.33
MEDIUMTEXT | 5,592,415 | 16,777,215 | 1,242,758.8 - 3,728,270
LONGTEXT | 1,431,655,765 | 4,294,967,295 | 318,145,725.5 - 954,437,176.6
Veuillez également vous référer à la réponse de Chris V : https://stackoverflow.com/a/35785869/1881812
Quelle est la justification de ce "Un VARCHAR devrait toujours être utilisé au lieu de TINYTEXT" ? Ne serait-il pas préférable (parce que plus efficace en termes de stockage) d'utiliser parfois le plus petit TINYTEXT ?
@vlasits lire le post SO inclus pour les détails. (1) tous les types de texte, y compris tinytext, sont stockés en tant qu'objets à l'extérieur de la ligne, ce qui représente une surcharge (2) ces objets sont ensuite référencés par des adresses de 8 ou 16 octets. ainsi, peu importe la taille de votre tinytext, vous ajoutez des surcharges inutiles, et ce pour une taille maximale de 255 octets. il est clair que varchar devrait être utilisé, ce qui n'entraînera aucune des surcharges ci-dessus.
@Ankan-Zerob Étant donné qu'il semble très clair que TINYTEXT ne devrait jamais être utilisé par rapport à VARCHAR, quelle est la raison d'être de cette option ? Existe-t-il un cas d'utilisation obscur où elle est nécessaire ?
Pour relever le défi lancé par @Ankan-Zerob, voici mon estimation de la longueur maximale pouvant être stockée dans chaque type de texte mesuré en mots :
Type | Bytes | English words | Multi-byte words
-----------+---------------+---------------+-----------------
TINYTEXT | 255 | ±44 | ±23
TEXT | 65,535 | ±11,000 | ±5,900
MEDIUMTEXT | 16,777,215 | ±2,800,000 | ±1,500,000
LONGTEXT | 4,294,967,295 | ±740,000,000 | ±380,000,000
Sur Anglais 4,8 lettres par mot est probablement une bonne moyenne (ex. norvig.com/mayzner.html ), mais la longueur des mots varie en fonction du domaine (par exemple, langage parlé ou articles universitaires), il est donc inutile d'être trop précis. L'anglais est principalement composé de caractères ASCII à un octet, avec très occasionnellement des caractères à plusieurs octets, donc proche d'un octet par lettre. Il faut prévoir un caractère supplémentaire pour les espaces entre les mots, c'est pourquoi j'ai arrondi à la baisse à partir de 5,8 octets par mot. Les langues avec beaucoup d'accents, comme le polonais par exemple, stockent un peu moins de mots, tout comme l'allemand avec des mots plus longs.
Langues nécessitant multioctet Les caractères tels que le grec, l'arabe, l'hébreu, l'hindi, le thaï, etc., etc. nécessitent généralement deux octets par caractère en UTF-8. En supposant qu'il y ait 5 lettres par mot, j'ai arrondi à 11 octets par mot.
CJK scripts (Hanzi, Kanji, Hiragana, Katakana, etc) Je ne sais rien de ; je crois que les caractères nécessitent principalement 3 octets en UTF-8, et (avec une simplification massive) on pourrait considérer qu'ils utilisent environ 2 caractères par mot, donc ils seraient quelque part entre les deux autres. (Les scripts CJK sont susceptibles de nécessiter moins de stockage en utilisant l'UTF-16, selon).
Bien entendu, ces chiffres ne tiennent pas compte des frais de stockage, etc.
Les caractères CJK peuvent utiliser une séquence de 3 ou 4 octets : dev.mysql.com/doc/refman/5.7/fr/charset-unicode-utf8.html
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
37 votes
Prenons par exemple le type TEXT. Il peut contenir 65535 octets de données. UTF-8 contient des caractères multi-octets. Par conséquent, si vous remplissez le champ en utilisant uniquement le caractère danois "Ø", vous n'obtiendrez que 32767 caractères, car ce caractère UTF-8 est composé de deux octets. Si vous remplissez le champ avec "a", vous obtiendrez 65535 caractères.
3 votes
Pensez aussi à lire Quel DATATYPE est-il préférable d'utiliser TEXT ou VARCHAR ?