Tamaños máximos de almacenamiento de TINYTEXT, TEXT, MEDIUMTEXT y LONGTEXT
Según los documentos de MySQL , hay cuatro tipos de TEXTO:
- TEXTO PEQUEÑO
- TEXTO
- TEXTO MEDIO
- TEXTO LARGO
¿Cuál es la longitud máxima que puedo almacenar en una columna de cada tipo de datos suponiendo que la codificación de caracteres sea UTF-8?
De la documentación (MySQL 8) :
Tipo | Longitud máxima
--+-------------------------------------
TEXTO PEQUEÑO | 255 (2 8 −1) bytes
TEXTO | 65.535 (2 16 −1) bytes = 64 KiB
TEXTO MEDIO | 16.777.215 (2 24 −1) bytes = 16 MiB
TEXTO LARGO | 4.294.967.295 (2 32 −1) bytes = 4 GiB
Tenga en cuenta que la cantidad de caracteres que se pueden almacenar en su columna dependerá de la codificación de caracteres .
Ampliación de la misma respuesta.
- Esta publicación SO describe en detalle los gastos generales y los mecanismos de almacenamiento.
- Como se indicó en el punto (1), siempre se debe utilizar A VARCHAR en lugar de TINYTEXT. Sin embargo, cuando se utiliza VARCHAR, el tamaño máximo de fila no debe exceder los 65535 bytes.
- Como se describe aquí http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-utf8.html , máximo 3 bytes para utf-8.
¡ESTA ES UNA TABLA DE ESTIMACIÓN APROXIMADA PARA DECISIONES RÁPIDAS!
- Entonces, los supuestos del peor de los casos (3 bytes por carácter utf-8) al mejor de los casos (1 byte por carácter utf-8)
- Suponiendo que el idioma inglés tiene un promedio de 4,5 letras por palabra.
- x es el número de bytes asignados
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
Consulte también la respuesta de Chris V: https://stackoverflow.com/a/35785869/1881812
A la altura del desafío de @Ankan-Zerob, esta es mi estimación de la longitud máxima que se puede almacenar en cada tipo de texto medido en palabras :
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 inglés , 4,8 letras por palabra es probablemente un buen promedio (por ejemplo, norvig.com/mayzner.html ), aunque la longitud de las palabras variará según el dominio (por ejemplo, lenguaje hablado frente a artículos académicos), por lo que no tiene sentido ser demasiado preciso. El inglés se compone principalmente de caracteres ASCII de un solo byte, con muy ocasionales caracteres de varios bytes, muy cerca de un byte por letra. Se debe permitir un carácter adicional para los espacios entre palabras, por lo que redondeé hacia abajo desde 5,8 bytes por palabra. Los idiomas con muchos acentos, como por ejemplo el polaco, almacenarían un poco menos de palabras, al igual que, por ejemplo, el alemán con palabras más largas.
Los idiomas que requieren caracteres de varios bytes , como griego, árabe, hebreo, hindi, tailandés, etc., normalmente requieren dos bytes por carácter en UTF-8. Adivinando locamente 5 letras por palabra, redondeé hacia abajo desde 11 bytes por palabra.
Guiones CJK (Hanzi, Kanji, Hiragana, Katakana, etc.) No sé nada de ellos; Creo que los caracteres requieren principalmente 3 bytes en UTF-8 y (con una simplificación masiva) se podría considerar que usan alrededor de 2 caracteres por palabra, por lo que estarían en algún lugar entre los otros dos. (Es probable que los scripts CJK requieran menos almacenamiento usando UTF-16, dependiendo).
Por supuesto, esto ignora los gastos generales de almacenamiento, etc.
Esto es bueno pero no responde la pregunta:
"Siempre se debe utilizar un VARCHAR en lugar de TINYTEXT". Tinytext es útil si tiene filas anchas, ya que los datos se almacenan fuera del registro. Hay una sobrecarga de rendimiento, pero tiene una utilidad.
