tipo tinytext example mysql innodb

example - mysql tinytext vs varchar



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

Según la documentación de MySQL , hay cuatro tipos de TEXTO:

  1. TINTEXTO
  2. TEXTO
  3. MEDIUMTEXTO
  4. 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?


De la documentation :

Type | Maximum length -----------+------------------------------------- TINYTEXT | 255 (2 8−1) bytes TEXT | 65,535 (216−1) bytes = 64 KiB MEDIUMTEXT | 16,777,215 (224−1) bytes = 16 MiB LONGTEXT | 4,294,967,295 (232−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 .


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

Los idiomas que requieren caracteres de múltiples bytes , como el griego, el árabe, el hebreo, el hindi, el tailandés, etc., suelen requerir dos bytes por carácter en UTF-8. Conjeturando a las 5 letras por palabra, he redondeado desde 11 bytes por palabra.

Guiones CJK (Hanzi, Kanji, Hiragana, Katakana, etc.) de los que no sé nada; Creo que la mayoría de los caracteres requieren 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 utilizando UTF-16, dependiendo).

Esto es, por supuesto, ignorando los gastos generales de almacenamiento, etc.


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.


Expansión de la misma respuesta.

  1. Este post de SO: varchar (255) vs tinytext / tinyblob y varchar (65535) vs blob / text describe en detalle los gastos generales y los mecanismos de almacenamiento.
  2. Como se señala en el punto (1), siempre se debe usar un VARCHAR en lugar de TINYTEXT. Sin embargo, cuando se utiliza VARCHAR, el tamaño máximo de las filas no debe exceder los 65535 bytes.
  3. Tal 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 MESA DE ESTIMACIÓN RÁPIDA PARA DECISIONES RÁPIDAS!

  1. Por lo tanto, los supuestos del caso más desfavorable (3 bytes por carácter utf-8) al mejor caso (1 byte por carácter utf-8)
  2. Asumiendo que el idioma inglés tiene un promedio de 4.5 letras por palabra
  3. 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 | 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

Consulte también la respuesta de Chris V: https://.com/a/35785869/1881812