MySQL Table with TEXT column

Question

He estado trabajando en una base de datos y tengo que lidiar con un campo TEXT.

Ahora, creo que he visto algún lugar mencionando que sería mejor aislar la columna TEXT del resto de la tabla (ponerla en una tabla propia).

Sin embargo, ahora no puedo encontrar esta referencia en ningún lado y dado que fue hace bastante tiempo, estoy empezando a pensar que tal vez malinterpreté esta información.

Algunas investigaciones revelaron this, lo que sugiere que

separados texto/objetos binarios de metadatos, no ponen texto/manchas en los resultados si no los necesita.

Sin embargo, no estoy familiarizado con la definición de "metadatos" que se utiliza aquí.

Así que me pregunto si hay ventajas relevantes al poner una columna TEXT en una tabla propia. ¿Cuáles son los posibles problemas de tenerlo con el resto de los campos? ¿Y problemas potenciales de mantenerlo en una mesa separada?

Se supone que esta tabla (sin el campo TEXTO) se busca (SELECCIONA) con bastante frecuencia. ¿Es la "optimización prematura considerada malvada" importante aquí? (Si realmente existe una penalización en las columnas de TEXTO, es relevante como, ya que es bastante fácil cambiar esto más adelante si es necesario).

Además, ¿hay algún buen enlace sobre este tema? (Quizás las preguntas de stackoverflow &? He tratado de buscar este tema, pero solo encontré TEXT vs VARCHAR discusiones)

Answer 1

Sí, parece que has malinterpretado el significado de la oración. Lo que dice es que solo debes hacer SELECCIONAR, incluido un campo de texto si realmente necesitas el contenido de ese campo. Esto se debe a que las columnas TEXT/BLOB pueden contener grandes cantidades de datos que deberían enviarse a su aplicación; esto lleva tiempo y, por supuesto, recursos.

mejores deseos, Fabian

Answer 2

Puede haber algunas buenas razones para separar un campo de texto de su definición de la tabla. Por ejemplo, si está utilizando un ORM que carga el registro completo sin importar qué, puede querer crear una tabla de propiedades para mantener el campo de texto para que no se cargue todo el tiempo. Sin embargo, si está controlando el código al 100%, para mayor simplicidad, deje el campo sobre la mesa y luego solo selecciónelo cuando lo necesite para reducir la transferencia de datos y el tiempo de lectura.

Answer 3

La preocupación es que un texto de gran tamaño, como un camino de más de 8,192 bytes, provocará paginación excesiva y/o archivos de E/S durante consultas complejas en campos no indexados. En tales casos, es mejor migrar el campo grande a otra tabla y reemplazarlo con el id. De fila o índice de la nueva tabla (que entonces sería metadata ya que en realidad no contiene datos).

Las desventajas son: a) más complicado esquema b) Si el campo grande está utilizando inspeccionado o recuperada, no hay ninguna ventaja c) Asegurar la coherencia de datos es más complicado y una fuente potencial de malestar base de datos.

Answer 4

Probablemente esta sea una optimización prematura.Ajuste de rendimiento MySQL es realmente complicado y solo se puede hacer con datos de rendimiento real para su aplicación. He visto muchos intentos de adivinar qué hace que MySQL sea lento sin datos reales y el resultado siempre ha sido un esquema desordenado y un código complejo que en realidad dificultará el ajuste del rendimiento más adelante.

Comience con un esquema simple normalizado, luego cuando algo demuestre ser demasiado lento agregue una complejidad solo donde/si es necesario.

Como otros han señalado que la cita que mencionó es más aplicable a los resultados de la consulta que la definición del esquema, en cualquier caso su elección del motor de almacenamiento afectaría la validez del consejo de todos modos.

Si encuentra que necesita agregar la complejidad de mover columnas TEXT/BLOB a una tabla separada, entonces probablemente valga la pena considerar la opción de sacarlas de la base de datos por completo. A menudo, el almacenamiento de archivos tiene ventajas sobre el almacenamiento de la base de datos, especialmente si no realiza consultas relacionales sobre el contenido de la columna TEXTO/BLOB.

Básicamente, obtenga algunos datos antes de tomar cualquier consejo de ajuste de MySQL que obtenga en Internet, ¡incluido esto!

Answer 5

Los datos para una columna TEXT ya están almacenados por separado. Cada vez que SELECT * de una tabla con columna (s) de texto, cada fila en el conjunto de resultados requiere una búsqueda en el área de almacenamiento de texto. Esto, junto con la posibilidad muy real de grandes cantidades de datos, sería una gran carga para su sistema.

Mover la columna a otra tabla simplemente requiere una búsqueda adicional, una en la tabla secundaria y la normal en el área de almacenamiento de texto.

La única vez que mover columnas de TEXTO a otra tabla ofrecerá algún beneficio si hay una tendencia a seleccionar todas las columnas de las tablas. Esto simplemente está introduciendo una segunda mala práctica para compensar la primera. No debería decirse que el dos errores no es lo mismo que tres izquierdas.

Answer 6

Ahora, yo creo que he visto en algún lugar mencionar que sería mejor para aislar la columna de texto desde el resto de la mesa (poniéndolo en una mesa de su propia). Sin embargo, ahora no puedo encontrar esta referencia en ningún lado y dado que fue hace bastante tiempo, estoy empezando a pensar que tal vez malinterpreté esta información.

Probablemente vieron esto, desde el manual de MySQL http://dev.mysql.com/doc/refman/5.5/en/optimize-character.html

Si una tabla contiene columnas de cadenas, tales como nombre y dirección, pero muchas consultas no recuperar esas columnas, considerar dividir las columnas de cadena en una tabla separada y el uso de consultas de combinación con una clave externa cuando sea necesario. Cuando MySQL recupera cualquier valor de una fila, lee un bloque de datos que contiene todas las columnas de esa fila (y posiblemente otras filas adyacentes). Mantener cada fila pequeña, con solo las columnas usadas con más frecuencia, permite que más filas quepan en cada bloque de datos. Tales tablas compactas reducen el uso de memoria y E/S de disco para consultas comunes.

cual a la verdad le está diciendo que en MySQL se desaconseja mantener los datos de texto (BLOB y, como está escrito en otro lugar) en los cuadros buscados de manera frecuente