TINYTEXT, TEXT, MEDIUMTEXT et LONGTEXT tailles de stockage maximales

796

Selon la documentation MySQL , il existe quatre types de TEXTE:

TINYTEXT
TEXTE
MOYENTEXTE
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?

mysql innodb

— Lalith B
source

26

Prenons par exemple le type TEXT. Il peut contenir 65 535 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 32 767 caractères, car ce caractère UTF-8 est composé de deux octets. Si vous le remplissiez par "a", vous obtiendrez 65535 caractères.

— Andrew Plank

1

Pensez

— Somnath Muluk

1518

De la documentation :

      Type | Longueur maximale
----------- + -------------------------------------
  TINYTEXT | 255 (2 ⁸ −1) octets
      TEXTE | 65 535 (2 ¹⁶ −1) octets = 64 Ko
MEDIUMTEXT | 16 777 215 (2 ²⁴ −1) octets = 16 Mio
  LONGTEXT | 4 294 967 295 (2 ³² −1) octets = 4 Gio

Notez que le nombre de caractères pouvant être stockés dans votre colonne dépendra de l' encodage des caractères .

— Pont
source

3

@Bridge Je ne suis pas sûr de comprendre, mais cela signifie que TINYTEXT peut contenir jusqu'à 255 caractères, ai-je raison ???

— ltdev

9

@Lykos Oui, eh bien - selon les personnages. 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.

— Pont

4

@ aurel.g Voici comment vous répondez vraiment à 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 qu'un raccourci supplémentaire pour leur ... vue texte floue.

— cbmtrx

1

Il pourrait être utile d'ajouter que l'ordre de grandeur d'un caractère est de quelques octets (min. 1 je suppose). Donc, on pourrait stocker 10 000 à 50 000 caractères dans une colonne TEXTE, ...

— Vince

30

Pourquoi est-il plus difficile de trouver cela dans les documents que dans stackoverflow

— Boris D. Teoharov

245

Extension de la même réponse

Ce message SO décrit en détail les frais généraux et les mécanismes de stockage.
Comme indiqué au point (1), un VARCHAR doit toujours être utilisé à la place de TINYTEXT. Cependant, lorsque vous utilisez VARCHAR, la taille de ligne maximale ne doit pas dépasser 65 535 octets.
Comme indiqué ici http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-utf8.html , max 3 octets pour utf-8.

CECI EST UN TABLEAU D'ESTIMATION BRUT POUR DES DÉCISIONS RAPIDES!

Donc, les hypothèses les plus défavorables (3 octets par caractère utf-8) au meilleur cas (1 octet par caractère utf-8)
En supposant que la langue anglaise a une moyenne de 4,5 lettres par mot
x est le nombre d'octets alloués

xx

      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

— Ankan-Zerob
source

4

Quelle est la justification de cette "UN VARCHAR devrait toujours être utilisé au lieu de TINYTEXT"? Ne serait-il pas préférable (car plus efficace pour le stockage) d'utiliser parfois le plus petit TINYTEXT?

— vlasits

24

@vlasits a lu l'article SO inclus pour plus de détails. (1) tous les types de texte, y compris les minuscules, sont stockés en tant qu'objets en dehors de la ligne qui est un surdébit (2) Ces objets sont ensuite référencés par des adresses de 8 ou 16 octets. donc peu importe la taille de votre texte minuscule, vous ajoutez des frais généraux inutiles, cela aussi pour une taille maximale de 255 octets. il est clair que varchar doit être utilisé, qui n'aura aucun des frais généraux ci-dessus.

— Ankan-Zerob

4

@ Ankan-Zerob Étant donné qu'il semble très clair que TINYTEXT ne devrait jamais être utilisé sur VARCHAR, quelle est la justification de l'avoir même en option? Y a-t-il un cas d'utilisation obscur où cela est nécessaire?

— nextgentech

4

@nextgentech Jetez un œil sur dev.mysql.com/doc/refman/5.0/en/column-count-limit.html . Une taille d'enregistrement est limitée à 64 Ko. Une table est limitée à 4k colonnes. Un TINYTEXTcompte 1 octet + 8 octets par rapport à la taille de l'enregistrement, tandis qu'un VARCHAR(255)compte de 1 octet + 255 octets jusqu'à 2 octets + 1020 octets (4 octets de caractères UTF-8) par rapport à la taille d'enregistrement.

— Shi

2

J'aime exprimer la taille des champs en mots, mais ... L'anglais est normalement considéré comme ayant environ 5 caractères par mot, et il y a aussi un caractère d'espace à stocker; cependant, l'anglais sera toujours proche de 1 octet par caractère UTF-8, donc je diviserais par 6 donnant environ 40/10 000/2 700 000/710 000 000 mots pour les différentes tailles. Les langues avec beaucoup d'accents comme le polonais auraient un peu moins de mots; Grec, hébreu, arabe, etc. (avec principalement des séquences de 2 octets) environ la moitié; Les idéogrammes CJC sont des séquences de 3 ou 4 octets, mais je ne sais pas combien de temps les mots sont.

— ChrisV

44

Relevant le défi de @ Ankan-Zerob, voici mon estimation de la longueur maximale qui peut ê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

En anglais , 4,8 lettres par mot est probablement une bonne moyenne (par exemple norvig.com/mayzner.html ), bien que la longueur des mots varie en fonction du domaine (par exemple, langue parlée vs articles académiques), il n'y a donc aucun intérêt à être trop précis. L'anglais est principalement composé de caractères ASCII à un octet, avec des caractères à plusieurs octets très occasionnels, si proches d'un octet par lettre. Un caractère supplémentaire doit être autorisé pour les espaces entre les mots, j'ai donc arrondi à 5,8 octets par mot. Les langues avec beaucoup d'accents telles que le polonais stockent un peu moins de mots, comme par exemple l'allemand avec des mots plus longs.

Les langues nécessitant des caractères multi-octets 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. Devinant sauvagement à 5 lettres par mot, j'ai arrondi à 11 octets par mot.

Scripts CJK (Hanzi, Kanji, Hiragana, Katakana, etc.) Je ne sais rien; Je crois que les caractères nécessitent principalement 3 octets en UTF-8, et (avec une simplification massive), ils pourraient être considérés comme utilisant environ 2 caractères par mot, ils seraient donc quelque part entre les deux autres. (Les scripts CJK nécessiteront probablement moins de stockage en utilisant UTF-16, selon).

Ceci est bien sûr ignorer les frais généraux de stockage, etc.

— ChrisV
source

Les caractères CJK peuvent utiliser une séquence de 3 ou 4 octets: dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8.html

— Raptor

8

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

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

— colin0117
source