php - too - MySql Tinytext vs Varchar vs Char

varchar mysql length

Question

Construir un sistema que tiene el potencial de ser golpeado con golpes y tráfico. Es una configuración típica de Apache / PHP / MySql.

He desarrollado muchos sistemas antes, pero nunca tuve un escenario en el que realmente tuviera que tomar decisiones con respecto a la escalabilidad potencial de este tamaño. Tengo docenas de preguntas con respecto a la construcción de un sistema de este magniture, pero para esta pregunta en particular, estoy tratando de decidir qué usar como tipo de datos.

Aquí está la vista de 100 pies:

Tenemos una tabla que (entre otras cosas) tiene un campo de descripción . Hemos decidido limitarlo a 255 caracteres . Se podrá buscar ( es decir, mostrarme todas las entradas con una descripción que contenga ... ). Problema: es probable que esta tabla tenga millones y millones de entradas en algún momento ( o eso creemos ).

Todavía no he descubierto la estrategia para la búsqueda (es probable que el operador de MySQL LIKE sea lento y / o un cerdo, estoy adivinando para un número de registros tan grande), pero eso es para otra pregunta ASÍ. Para esta pregunta, me pregunto cuáles son los pro y los contras para crear este campo como un texto diminuto, varchar y char .

No soy un experto en bases de datos, por lo que todos y cada uno de los comentarios son útiles. Gracias -

Answer 1

Creo que con varchar tienes una longitud variable almacenada en la base de datos real en los niveles bajos, lo que significa que podría ocupar menos espacio en disco, con el campo de texto de longitud fija, incluso si una fila no usa todo. La cadena de longitud fija debería ser más rápida de consultar.

Editar : Acabo de buscarlo, los tipos de texto también se almacenan como longitud variable. Lo mejor que se puede hacer es compararlo con algo como mysqlslap

Con respecto a su otra pregunta no realizada, probablemente desee construir algún tipo de índice de búsqueda que vincule individualmente cada palabra útil en el campo de descripción con una descripción, luego puede indexarla y buscarla en su lugar. será mucho más rápido que usar% como%.

Answer 2

En su situación, los tres tipos son malos si usa LIKE (un LIKE ''%string%'' no usará ningún índice creado en esa columna, independientemente de su tipo). Todo lo demás es solo ruido.

No estoy al tanto de ninguna diferencia importante entre TINYTEXT y VARCHAR hasta 255 caracteres, y CHAR es para cadenas de longitud variable.

Así que mi sugerencia: elegir VARCHAR o TINYTEXT (me gustaría ir personalmente a VARCHAR) e indexar el contenido de esa columna usando un motor de búsqueda de texto completo como Lucene, Sphinx o cualquier otro que haga el trabajo por usted. Solo olvídate de LIKE (incluso si eso significa que necesitas construir el motor de índice de búsqueda de texto completo por las razones que tengas, es decir, necesitas soporte para un conjunto de características que ningún motor puede satisfacer).

Answer 3

Si desea buscar entre millones de filas, almacene todos estos textos en una tabla diferente (lo que disminuirá el tamaño de la fila de su gran mesa) y use VARCHAR si los datos de texto son cortos, o TEXTO si necesita una mayor longitud.

En lugar de buscar con LIKE use una solución especializada como Lucene, Sphinx o Solr. No recuerdo cuál, pero al menos uno de ellos se puede configurar fácilmente para la indexación en tiempo real o casi en tiempo real.

EDITAR

Mi proposición de almacenar texto en diferentes tablas reduce IO requerido para la tabla principal, pero cuando se insertan datos requiere mantener un índice adicional y agrega sobrecarga de selección en selecciones, por lo que es válido solo si usa su tabla para leer algunas descripciones a la vez y otros datos de la tabla se usan con más frecuencia.

Answer 4

Use un CHAR .

BLOB y TEXT se almacenan fuera de la fila, por lo que habrá una penalización de acceso para leerlos. VARCHAR son de longitud variable, lo que ahorra espacio de almacenamiento al introducir una pequeña penalización de acceso (ya que las filas no son todas de longitud fija).

Sin embargo, si crea su índice correctamente, VARCHAR o CHAR se pueden almacenar por completo en el índice, lo que hará que el acceso sea mucho más rápido.

Ver: varchar (255) v tinyblob v tinytext
Y: http://213.136.52.31/mysql/540
Y: http://forums.mysql.com/read.php?10,254231,254231#msg-254231
Y: http://forums.mysql.com/read.php?20,223006,223683#msg-223683

Por cierto, en mi experiencia, el operador de regex MySQL es mucho más rápido que LIKE para consultas simples (es decir, SELECT ID WHERE SOME_COLUMN REGEX ''search.*'' ), Y obviamente es más versátil.