Question TINYTEXT, TEXT, MEDIUMTEXT et LONGTEXT tailles de stockage maximales


Par les docs MySQL, il y a quatre types de TEXT:

  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 de caractères est UTF-8?


630
2017-12-18 12:13


origine


Réponses:


Du Documentation :

      Type | Longueur maximale
----------- + -------------------------------------
  TINYTEXT | 255 (2 8-1) octets
      TEXT | 65 535 (216-1) octets = 64 KiB
MEDIUMTEXT | 16 777 215 (224-1) octets = 16 Mio
  LONGTEXT | 4 294 967 295 (232-1) octets = 4 Gio

Notez que le nombre de personnages qui peut être stocké dans votre colonne dépendra de la Encodage de caractère.


1264
2017-12-18 12:18



Expansion de la même réponse

  1. Ce message SO: varchar (255) par rapport à tinytext / tinyblob et varchar (65535) vs blob / text décrit en détail les frais généraux et les mécanismes de stockage.
  2. Comme indiqué au point (1), A VARCHAR devrait toujours être utilisé à la place de TINYTEXT. Toutefois, lors de l'utilisation de VARCHAR, la valeur maximale de rowsize 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 octets pour utf-8.

C'EST UNE TABLE D'ESTIMATION RUGUEUSE POUR DES DÉCISIONS RAPIDES!

  1. Donc, les hypothèses les plus défavorables (3 octets par caractère utf-8) au meilleur des cas (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 |           21845     | 65,535            | 4854.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 vous référer à la réponse de Chris V: https://stackoverflow.com/a/35785869/1881812


197
2018-04-19 12:18



Pour relever le défi de @ 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

Dans 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, la langue parlée par rapport aux articles universitaires), donc il ne sert à rien d'être trop précis. L'anglais est principalement composé de caractères ASCII à un octet, avec des caractères multi-octets très occasionnels, donc proches d'un octet par lettre. Un caractère supplémentaire doit être autorisé pour les espaces inter-mots, donc j'ai arrondi à partir de 5,8 octets par mot. Les langues avec beaucoup d'accents tels que le polonais stockent un peu moins de mots, comme par exemple. Allemand avec des mots plus longs.

Langues nécessitant multi-octets Les caractères tels que le grec, l'arabe, l'hébreu, l'hindi, le thaïlandais, etc., nécessitent généralement deux octets par caractère en UTF-8. Devinant follement à 5 lettres par mot, j'ai arrondi de 11 octets par mot.

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

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


31
2018-03-04 00:33



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

"Un VARCHAR devrait toujours être utilisé à la place de TINYTEXT." Tinytext est utile si vous avez des lignes larges - puisque les données sont stockées hors de l'enregistrement. Il y a un surcoût de performance, mais il a une utilité.


3
2018-05-18 15:36