TINYTEXT, TEXT, MEDIUMTEXT e LONGTEXT dimensioni massime di archiviazione

796

Secondo i documenti MySQL , ci sono quattro tipi di TESTO:

TINYTEXT
TESTO
MEDIUMTEXT
LONGTEXT

Qual è la lunghezza massima che posso memorizzare in una colonna di ciascun tipo di dati supponendo che la codifica dei caratteri sia UTF-8?

mysql innodb

— Lalith B
fonte

26

Prendi ad esempio il tipo TEXT. Può contenere 65535 byte di dati. UTF-8 contiene caratteri multi-byte. Pertanto, se si riempiva il campo utilizzando solo il carattere danese "Ø", si otterrebbero solo 32767 caratteri, poiché quel carattere UTF-8 è composto da due byte. Se lo riempissi con "a", otterrai 65535 caratteri.

— Andrew Plank,

1

Considera anche di leggere Quale DATATYPE è meglio usare TEXT o VARCHAR

— Somnath Muluk

1518

Dalla documentazione :

      Digita | Lunghezza massima
----------- + -------------------------------------
  TINYTEXT | 255 (2 ⁸ −1) byte
      TESTO | 65.535 (2 ¹⁶ −1) byte = 64 KiB
MEDIUMTEXT | 16.777.215 (2 ²⁴ −1) byte = 16 MiB
  LONGTEXT | 4.294.967.295 (2 ³² −1) byte = 4 GiB

Nota che il numero di caratteri che possono essere memorizzati nella tua colonna dipenderà dalla codifica dei caratteri .

— ponte
fonte

3

@Bridge Non sono sicuro di aver capito, ma questo significa che TINYTEXT può contenere fino a 255 caratteri, ho ragione ???

— ltd,

9

@Lykos Sì, bene - a seconda dei personaggi. Dalla documentazione:

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.

vedi la risposta di Ankan per maggiori dettagli.

— Bridge,

4

@ aurel.g Ecco come rispondi davvero alla domanda. E sono d'accordo con Christophe, è così che mySQL dovrebbe presentare i suoi parametri, anche se solo una scorciatoia supplementare alla loro ... visione di testo arcana.

— cbmtrx,

1

Potrebbe valere la pena aggiungere che l'ordine di grandezza di un personaggio è un paio di byte (suppongo minimo 1). Quindi si potrebbero memorizzare 10.000-50.000 caratteri in una colonna TEXT, ...

— Vince il

30

Perché è più difficile trovarlo nei documenti che nello

— stackoverflow

245

Espansione della stessa risposta

Questo post SO illustra in dettaglio i costi generali e i meccanismi di archiviazione.
Come notato dal punto (1), A VARCHAR dovrebbe essere sempre usato al posto di TINYTEXT. Tuttavia, quando si utilizza VARCHAR, la dimensione massima delle righe non deve superare 65535 byte.
Come indicato qui http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-utf8.html , max 3 byte per utf-8.

QUESTA È UNA TABELLA PREVENTIVA PER LE DECISIONI RAPIDE!

Quindi i presupposti peggiori (3 byte per carattere utf-8) nel caso migliore (1 byte per carattere utf-8)
Supponendo che la lingua inglese abbia una media di 4,5 lettere per parola
x è il numero di byte assegnati

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

Fare riferimento anche alla risposta di Chris V: https://stackoverflow.com/a/35785869/1881812

— Ankan-Zerob
fonte

4

Qual è la logica di questo "A VARCHAR dovrebbe sempre essere usato al posto di TINYTEXT"? Non sarebbe meglio (perché più efficiente nell'archiviazione) utilizzare il TINYTEXT più piccolo a volte?

— vlasits,

24

@vlasits leggi il post SO incluso per i dettagli. (1) tutti i tipi di testo, incluso tinytext, sono memorizzati come oggetti all'esterno della riga che è un overhead (2) A questi oggetti viene quindi fatto riferimento da indirizzi 8 o 16 byte. quindi, non importa quanto minuscolo sia il tuo testo minuscolo, stai aggiungendo spese generali non necessarie, anche per una dimensione massima di 255 byte. è chiaro che varchar dovrebbe essere usato, che non avrà nessuna delle suddette spese generali.

— Ankan-Zerob,

4

@ Ankan-Zerob Dato che sembra molto chiaro che TINYTEXT non dovrebbe mai essere usato su VARCHAR, qual è la logica per averlo come opzione? C'è qualche caso oscuro dove è necessario?

— nextgentech,

4

@nextgentech Dai un'occhiata a dev.mysql.com/doc/refman/5.0/en/column-count-limit.html . Una dimensione record è limitata a 64 KiB. Una tabella è limitata a 4k colonne. A TINYTEXTconta 1 byte + 8 byte rispetto alla dimensione del record, mentre a VARCHAR(255)conta da 1 byte + 255 byte fino a 2 byte + 1020 byte (4 byte UTF-8 caratteri) rispetto alla dimensione del record.

— Shi,

2

Mi piace esprimere le dimensioni dei campi in parole, ma ... l'inglese è normalmente considerato avere circa 5 caratteri per parola, e c'è anche un carattere spaziale da memorizzare; tuttavia, l'inglese sarà sempre vicino a 1 byte per carattere UTF-8, quindi dividerei per 6 dando circa 40 / 10.000 / 2.700.000 / 710.000.000 di parole per le diverse dimensioni. Le lingue con molti accenti come il polacco avrebbero un numero leggermente inferiore di parole; Greco, ebraico, arabo, ecc. (Con sequenze prevalentemente a 2 byte) circa la metà; Gli ideogrammi CJK sono sequenze di 3 o 4 byte, ma non so quanto siano lunghe le parole.

— ChrisV,

44

In vista della sfida di @ Ankan-Zerob, questa è la mia stima della lunghezza massima che può essere memorizzata in ciascun tipo di testo misurato in parole :

      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

In inglese , 4,8 lettere per parola sono probabilmente una buona media (ad es. Norvig.com/mayzner.html ), sebbene la lunghezza delle parole varierà in base al dominio (ad es. Lingua parlata vs. documenti accademici), quindi non ha senso essere troppo precisi. L'inglese è per lo più caratteri ASCII a byte singolo, con caratteri multi-byte molto occasionali, quindi vicini a un byte per lettera. È necessario consentire un carattere aggiuntivo per gli spazi tra parole, quindi ho arrotondato per difetto da 5,8 byte per parola. Le lingue con molti accenti come il polacco memorizzano un numero leggermente inferiore di parole, come ad esempio il tedesco con parole più lunghe.

Le lingue che richiedono caratteri multi-byte come greco, arabo, ebraico, hindi, tailandese, ecc., In genere richiedono due byte per carattere in UTF-8. Indovinando selvaggiamente 5 lettere per parola, ho arrotondato per difetto da 11 byte per parola.

Script CJK (Hanzi, Kanji, Hiragana, Katakana, ecc.) Di cui non so nulla; Credo che i caratteri richiedano principalmente 3 byte in UTF-8 e (con enorme semplificazione) potrebbero essere considerati in grado di utilizzare circa 2 caratteri per parola, quindi si troverebbero in qualche punto tra gli altri due. (È probabile che gli script CJK richiedano meno spazio di archiviazione utilizzando UTF-16, a seconda).

Questo ovviamente ignora le spese generali di archiviazione, ecc.

— ChrisV
fonte

I caratteri CJK possono utilizzare una sequenza di 3 o 4 byte: dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8.html

— Raptor

8

Questo è carino ma non risponde alla domanda:

"Un VARCHAR dovrebbe essere sempre usato al posto di TINYTEXT." Tinytext è utile se si dispone di righe larghe, poiché i dati vengono archiviati nel registro. C'è un sovraccarico di prestazioni, ma ha un uso.

— colin0117
fonte