Tamaños máximos de almacenamiento TINYTEXT, TEXT, MEDIUMTEXT y LONGTEXT

796

Según los documentos de MySQL , hay cuatro tipos de TEXTO:

TINYTEXT
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 es UTF-8?

mysql innodb

— Lalith B
fuente

26

Tomemos, por ejemplo, el tipo de texto. Puede contener 65535 bytes de datos. UTF-8 contiene caracteres de varios bytes. Por lo tanto, si completa el campo utilizando solo el carácter danés "Ø", solo obtendrá 32767 caracteres, ya que ese carácter UTF-8 se compone de dos bytes. Si lo llena con "a", obtendrá 65535 caracteres.

— Andrew Plank

1

También considere leer Qué tipo de datos es mejor usar TEXTO o VARCHAR

— Somnath Muluk

1518

De la documentación :

      Tipo | Longitud máxima
----------- + -------------------------------------
  TINYTEXT | 255 (2 ⁸ −1) bytes
      TEXTO | 65,535 (2 ¹⁶ −1) bytes = 64 KiB
MEDIUMTEXT | 16.777.215 (2 ²⁴ −1) bytes = 16 MiB
  LONGTEXT | 4,294,967,295 (2 ³² −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 .

— Puente
fuente

3

@Bridge No estoy seguro de entender, pero esto significa que TINYTEXT puede obtener hasta 255 caracteres, ¿estoy en lo cierto?

— ltdev

99

@Lykos Sí, bueno, dependiendo de los personajes. De la documentación:

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.

Vea la respuesta de Ankan para más detalles.

— Puente

44

@ aurel.g Así es como realmente responde la pregunta. Y estoy de acuerdo con Christophe, así es como mySQL debería presentar sus parámetros, incluso como una abreviatura complementaria a su ... vista de texto arcano.

— cbmtrx

1

Podría valer la pena agregar que el orden de magnitud de un carácter es un par de bytes (mínimo 1, supongo). Entonces uno podría almacenar 10,000-50,000 caracteres en una columna de TEXTO, ...

— Vince

30

¿Por qué es más difícil encontrar esto en los documentos que en stackoverflow?

— Boris D. Teoharov

245

Expansión de la misma respuesta

Esta publicación SO describe en detalle los gastos generales y los mecanismos de almacenamiento.
Como se señaló en el punto (1), A VARCHAR siempre debe usarse en lugar de TINYTEXT. Sin embargo, cuando se utiliza VARCHAR, el tamaño máximo de filas 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 EN BRUTO PARA DECISIONES RÁPIDAS!

Entonces, los supuestos del peor caso (3 bytes por utf-8 char) al mejor caso (1 byte por utf-8 char)
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

— Ankan-Zerob
fuente

44

¿Cuál es el fundamento de este "A VARCHAR siempre debe usarse en lugar de TINYTEXT"? ¿No sería mejor (porque es más eficiente en el almacenamiento) usar el TINYTEXT más pequeño a veces?

— vlasits

24

@vlasits lee la publicación SO incluida para más detalles. (1) todos los tipos de texto, incluido tinytext, se almacenan como objetos fuera de la fila, que es una sobrecarga (2) A estos objetos se hace referencia mediante direcciones de 8 o 16 bytes. así que no importa cuán pequeño sea su pequeño texto, está agregando gastos generales innecesarios, eso también para un tamaño máximo de 255 bytes. está claro que se debe usar varchar, que no tendrá ninguno de los gastos generales anteriores.

— Ankan-Zerob

44

@ Ankan-Zerob Dado que parece muy claro que TINYTEXT nunca debe usarse sobre VARCHAR, ¿cuál es la razón para incluso tenerlo como una opción? ¿Hay algún caso de uso oscuro donde sea necesario?

— nextgentech

44

@nextgentech Eche un vistazo a dev.mysql.com/doc/refman/5.0/en/column-count-limit.html . Un tamaño de registro está limitado a 64 KiB. Una tabla está limitada a 4k columnas. A TINYTEXTcuenta 1 byte + 8 byte contra el tamaño del registro, mientras que VARCHAR(255)cuenta desde 1 byte + 255 byte hasta 2 byte + 1020 byte (4 bytes UTF-8 caracteres) contra el tamaño del registro.

— Shi

2

Me gusta expresar los tamaños de campo en palabras, pero ... normalmente se considera que el inglés tiene alrededor de 5 caracteres por palabra, y también hay un espacio para ser almacenado; sin embargo, el inglés siempre estará cerca de 1 byte por carácter UTF-8, por lo que dividiría por 6 dando alrededor de 40 / 10,000 / 2,700,000 / 710,000,000 palabras para los diferentes tamaños. Los idiomas con muchos acentos como el polaco tendrían un poco menos de palabras; Griego, hebreo, árabe, etc. (con secuencias principalmente de 2 bytes) aproximadamente la mitad; Las ideografías CJK son secuencias de 3 o 4 bytes, pero no sé cuánto duran las palabras.

— ChrisV

44

En respuesta al 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 (p. Ej ., Norvig.com/mayzner.html ), aunque la longitud de las palabras variará según el dominio (p. Ej., Lenguaje hablado frente a documentos académicos), por lo que no tiene sentido ser demasiado preciso. El inglés es principalmente caracteres ASCII de un solo byte, con caracteres de varios bytes muy ocasionales, muy cerca de un byte por letra. Se debe permitir un carácter adicional para los espacios entre palabras, por lo que he redondeado hacia abajo desde 5.8 bytes por palabra. Los idiomas con muchos acentos, como el polaco, almacenarían un poco menos de palabras, como por ejemplo el alemán con palabras más largas.

Los idiomas que requieren caracteres de varios bytes como el griego, árabe, hebreo, hindi, tailandés, etc., generalmente requieren dos bytes por carácter en UTF-8. Adivinando salvajemente a 5 letras por palabra, he redondeado hacia abajo desde 11 bytes por palabra.

Guiones de CJK (Hanzi, Kanji, Hiragana, Katakana, etc.) No sé nada; 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.

— ChrisV
fuente

Los caracteres CJK pueden usar una secuencia de 3 o 4 bytes: dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8.html

— Raptor

8

Esto es bueno pero no responde la pregunta:

"Siempre se debe usar 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 un uso.

— colin0117
fuente