921 votes

Tailles maximales de stockage des TINYTEXT, TEXT, MEDIUMTEXT et LONGTEXT

Par les documents MySQL il existe quatre types de TEXTE :

  1. TINYTEXT
  2. TEXTE
  3. MEDIUMTEXT
  4. 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 ?

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

1719voto

Bridge Points 8880

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 .

3 votes

@Bridge Je ne suis pas sûr de comprendre, mais cela signifie que le TINYTEXT peut atteindre 255 caractères, n'est-ce pas ???

10 votes

@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.

5 votes

@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.

286voto

Ankan-Zerob Points 406

Expansion de la même réponse

  1. Ce site SO post décrit en détail les frais généraux et les mécanismes de stockage.
  2. Comme indiqué au point (1), il faut toujours utiliser un VARCHAR au lieu de TINYTEXT. Toutefois, lorsque vous utilisez VARCHAR, la taille maximale des lignes ne doit pas dépasser 65535 octets.
  3. Comme indiqué ici http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-utf8.html , max 3 bytes pour utf-8.

IL S'AGIT D'UN TABLEAU D'ESTIMATION APPROXIMATIF POUR DES DÉCISIONS RAPIDES !

  1. Donc, de la pire des hypothèses (3 octets par caractère utf-8) à la meilleure (1 octet par caractère utf-8).
  2. En supposant que la langue anglaise a une moyenne de 4.5 lettres par mot.
  3. x est le nombre d'octets alloués

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

4 votes

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 ?

27 votes

@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.

4 votes

@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 ?

56voto

ChrisV Points 1832

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.

0 votes

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

12voto

colin0117 Points 928

C'est bien mais ça ne répond pas à la question :

"Un VARCHAR devrait toujours être utilisé au lieu de TINYTEXT". Tinytext est utile si vous avez des rangées larges - puisque les données sont stockées hors de l'enregistrement. Il y a une surcharge de performance, mais il a une utilité.

Prograide.com

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.

Powered by:

X