MySQL: ¿VARCHAR grande vs. TEXTO?

Tengo una tabla de mensajes en MySQL que registra los mensajes entre usuarios. Además de los identificadores y tipos de mensaje típicos (todos los tipos enteros), necesito guardar el texto del mensaje real como VARCHAR o TEXT. Estoy estableciendo un límite frontal de 3000 caracteres, lo que significa que los mensajes nunca se insertarán en la base de datos más tiempo que esto.

¿Existe una justificación para utilizar VARCHAR (3000) o TEXT? Hay algo acerca de solo escribir VARCHAR (3000) que se siente algo contra-intuitivo. He leído otras publicaciones similares en Stack Overflow, pero sería bueno obtener vistas específicas para este tipo de almacenamiento de mensajes comunes.

• TEXTy BLOB puede almacenarse fuera de la tabla con la tabla simplemente con un puntero a la ubicación del almacenamiento real. El lugar donde se almacena depende de muchas cosas, como el tamaño de los datos, el tamaño de las columnas, el formato de fila y la versión de MySQL.

• VARCHARse almacena en línea con la tabla. VARCHARes más rápido cuando el tamaño es razonable, cuya compensación sería más rápida depende de sus datos y su hardware, querría comparar un escenario del mundo real con sus datos.

¿Puedes predecir cuánto tiempo duraría la entrada del usuario?

VARCHAR (X)

Caso: nombre de usuario, correo electrónico, país, asunto, contraseña

---

TEXTO

Caso: mensajes, correos electrónicos, comentarios, texto formateado, html, código, imágenes, enlaces

---

TEXTO MEDIO

Caso: grandes cuerpos json, libros cortos a medianos, cadenas csv

---

TEXTO LARGO

Caso: libros de texto, programas, años de archivos de registros, Harry Potter y el cáliz de fuego, registro de investigaciones científicas

Solo para aclarar la mejor práctica:

1. Los mensajes de formato de texto casi siempre deben almacenarse como TEXTO (terminan siendo arbitrariamente largos)

2. Los atributos de cadena deben almacenarse como VARCHAR (el nombre de usuario de destino, el asunto, etc.).

Entiendo que tienes un límite frontal, lo cual es genial hasta que no lo sea. * sonrisa * El truco es pensar en el DB como algo separado de las aplicaciones que se conectan a él. El hecho de que una aplicación ponga un límite a los datos, no significa que los datos estén intrínsecamente limitados.

¿Qué tienen los mensajes mismos que los obliga a nunca tener más de 3000 caracteres? Si es solo una restricción de aplicación arbitraria (por ejemplo, para un cuadro de texto o algo así), use un TEXTcampo en la capa de datos.

Descargo de responsabilidad: no soy un experto en MySQL ... pero esta es mi comprensión de los problemas.

Creo que TEXT se almacena fuera de la fila mysql, mientras que VARCHAR se almacena como parte de la fila. Hay una longitud máxima de fila para las filas mysql ... por lo que puede limitar la cantidad de otros datos que puede almacenar en una fila utilizando VARCHAR.

También debido a que VARCHAR forma parte de la fila, sospecho que las consultas que miran ese campo serán un poco más rápidas que las que usan un fragmento de TEXTO.

Respuesta corta: no hay diferencias prácticas, de rendimiento o de almacenamiento.

Respuesta larga:

Esencialmente no hay diferencia (en MySQL) entre VARCHAR(3000)(o cualquier otro límite grande) y TEXT. El primero se truncará a 3000 caracteres ; este último se truncará a 65535 bytes . (Hago una distinción entre bytes y caracteres porque un personaje puede tomar varios bytes).

Para límites más pequeños VARCHAR, hay algunas ventajas sobre TEXT.

• "más pequeño" significa 191, 255, 512, 767 o 3072, etc., según la versión, el contexto y CHARACTER SET.
• INDEXesestán limitados en qué tan grande se puede indexar una columna. (767 o 3072 bytes ; esto depende de la versión y la configuración)
• Las tablas intermedias creadas por complex SELECTsse manejan de dos maneras diferentes: MEMORY (más rápido) o MyISAM (más lento). Cuando están involucradas columnas 'grandes', la técnica más lenta se selecciona automáticamente. (Cambios significativos en la versión 8.0; por lo tanto, este elemento de viñeta está sujeto a cambios).
• En relación con el elemento anterior, todos los TEXTtipos de datos (en oposición a VARCHAR) saltan directamente a MyISAM. Es decir, TINYTEXTes automáticamente peor para las tablas temporales generadas que el equivalente VARCHAR. (¡Pero esto lleva la discusión en una tercera dirección!)
• VARBINARYes como VARCHAR; BLOBes como TEXT.

Refutación a otras respuestas.

La pregunta original preguntaba una cosa (qué tipo de datos usar); la respuesta aceptada respondió algo más (almacenamiento no registrado). Esa respuesta ahora está desactualizada.

Cuando este hilo se inició y respondió, solo había dos "formatos de fila" en InnoDB. Poco después, se introdujeron dos formatos más ( DYNAMICy COMPRESSED).

La ubicación de almacenamiento para TEXTy VARCHAR()se basa en el tamaño , no en el nombre del tipo de datos . Para una discusión actualizada sobre el almacenamiento dentro / fuera del registro de grandes columnas de texto / blob, vea esto .

Las respuestas anteriores no insisten lo suficiente en el problema principal: incluso en consultas muy simples como

(SELECT t2.* FROM t1, t2 WHERE t2.id = t1.id ORDER BY t1.id) 

Se puede requerir una tabla temporal, y si un VARCHARcampo está involucrado, se convierte en un CHARcampo en la tabla temporal. Entonces, si tiene en su tabla 500,000 líneas con un VARCHAR(65000)campo, esta columna solo usará 6.5 * 5 * 10 ^ 9 byte. Dichas tablas temporales no se pueden manejar en la memoria y se escriben en el disco. Se puede esperar que el impacto sea catastrófico.

Fuente (con métricas): https://nicj.net/mysql-text-vs-varchar-performance/ (Esto se refiere al manejo de TEXTvs VARCHARen el motor de almacenamiento MyISAM "estándar" (?). Puede ser diferente en otros, por ejemplo, InnoDB.)

Hay una GRAN diferencia entre VARCHAR y TEXT. Mientras que los campos VARCHAR pueden indexarse, los campos TEXT no pueden. Los campos de tipo VARCHAR se almacenan en línea mientras que TEXT se almacenan fuera de línea, solo los punteros a los datos de TEXT se almacenan realmente en los registros.

Si tiene que indexar su campo para buscar, actualizar o eliminar más rápidamente que ir a VARCHAR, no importa cuán grande sea. Un VARCHAR (10000000) nunca será lo mismo que un campo TEXTO porque estos dos tipos de datos son de naturaleza diferente.

• Si usa su campo solo para archivar
• no te importa la recuperación de la velocidad de datos
• le importa la velocidad, pero usará el operador '% LIKE%' en su consulta de búsqueda, por lo que la indexación no ayudará mucho
• no puedes predecir un límite de longitud de datos

que ir a TEXTO.

Varchar es para datos pequeños como direcciones de correo electrónico, mientras que Text es para datos mucho más grandes como artículos de noticias, Blob para datos binarios como imágenes.

El rendimiento de Varchar es más potente porque se ejecuta completamente desde la memoria, pero este no será el caso si los datos son demasiado grandes como, varchar(4000)por ejemplo.

El texto, por otro lado, no se adhiere a la memoria y se ve afectado por el rendimiento del disco, pero puede evitarlo separando los datos de texto en una tabla separada y aplicando una consulta de unión izquierda para recuperar datos de texto.

Blob es mucho más lento, así que úselo solo si no tiene muchos datos como 10000 imágenes que costarán 10000 registros.

Siga estos consejos para obtener la máxima velocidad y rendimiento:

1. Use varchar para nombre, títulos, correos electrónicos

2. Usar texto para datos grandes

3. Texto separado en diferentes tablas

4. Use las consultas de combinación izquierda en una identificación, como un número de teléfono

5. Si va a usar Blob, aplique los mismos consejos que en Text

Esto hará que las consultas cuesten milisegundos en tablas con datos> 10 M y un tamaño de hasta 10 GB garantizado.