¿El tamaño del campo afecta el tiempo de consulta?

Question

Mi pregunta es respecto a MySQL, pero también me pregunto cómo afecta esto a otras bases de datos. Tengo varios campos que son varchar(255) pero mi compañero de trabajo insiste en que si fueran varchar(30), o cualquier tamaño más pequeño, las consultas se ejecutarían más rápido. No estoy tan seguro, pero si es así, lo admitiré.

Answer 1

Si usted está usando solamente siempre los primeros 30 caracteres, entonces habrá no haber una diferencia entre un varchar (30) y un varchar (255) (aunque no habría una diferencia con varchar (1000), que tomaría un byte extra).

Por supuesto, si termina usando más de 30 caracteres, será más lento ya que tendrá más datos para pasar al cliente, y sus índices serán más grandes.

Answer 2

Depende de la consulta y de los datos, pero probablemente esté optimizando demasiado pronto como para preocuparse.

Para las consultas SELECT, la instrucción se ejecutará igual de rápido dentro de MySQL, y siempre que los datos no sean mayores de lo que serían en el campo de menor tamaño, se transmitirá con la misma rapidez. Si el campo más pequeño te obliga a almacenar la información en un espacio más pequeño (¿usarías 225 caracteres adicionales?), Obtendrás una transmisión rápida a otros programas.

Para las consultas INSERT, el tamaño del campo no es un problema, pero el uso de campos de longitud variable ralentizará el proceso. Los INSERT con filas de longitud fija son notablemente más rápidos (al menos en MySQL 5.0 y anteriores). Por lo general, use el tamaño que necesita para los datos. Si no sabe si necesita 255 caracteres o 30 caracteres, probablemente esté optimizando demasiado pronto. ¿Los campos de datos grandes causan un cuello de botella? ¿Su programa sufre problemas de rendimiento de base de datos? Encuentra tus cuellos de botella primero, resuelve el problema con ellos en segundo lugar. Supongo que la diferencia en el tiempo que estás viendo aquí no es importante para cualquier problema que estés tratando de resolver.

Answer 3

Cualquier cosa menor que VARCHAR (255) usará un byte para almacenar su tamaño , por lo que VARCHAR (30) y VARCHAR (255) no harán la diferencia.

Pero eche un vistazo si sus datos son consistentes, quiero decir, siempre del mismo tamaño, en ese caso usar un CHAR sería más útil porque no perderá tiempo con la información de tamaño y su búsqueda sería más simple de encontrar los datos, no en el índice de la cuenta aquí.

Incluso si sus datos no son consistentes pero cambian en un factor de, digamos, un byte, un CHAR sería mejor, porque de todos modos perderá un byte con información de tamaño.

Answer 4

Muy raramente el ancho de la columna afectará el rendimiento de la consulta. Ciertamente, si está usando objetos más grandes (BLOB, LONGBLOB, TEXT, LONGTEXT), existe la posibilidad de que se extraigan muchos datos. Eso podría afectar el rendimiento, pero no necesariamente. Eso realmente solo afecta el almacenamiento. Si le importa el tamaño de almacenamiento por tipo de datos, puede hacer referencia al http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html para ver los detalles.

Y reiterar: el tamaño de almacenamiento de los datos no afecta necesariamente la velocidad de las consultas. Hay muchas otras consideraciones de diseño que afectarán la velocidad de la consulta. Diseño de las tablas y relaciones, estructura clave, índices, consultas y unirse a la arquitectura, etc. Hace

Answer 5

unos años muchas personas sugirieron utilizar tinytext en lugar de varchar en MySQL para el rendimiento, ya que la fila por fila de búsqueda supuestamente era más rápido con constantes tamaño de datos de fila. Seguramente los algoritmos de administración de consultas, almacenamiento e índices de MySQL evolucionaron desde entonces y ahora puede no tener tanto impacto.

Pero probablemente esté optimizando demasiado pronto y no debería preocuparse por el rendimiento en este nivel.

Answer 6

Puesto que usted preguntará sobre otras bases de datos ...

absolutamente Cómo afecta el tiempo de consulta.

En Oracle, cuando los datos se trasladan de un Servidor a otro, se realizan a través de un búfer. Nada revolucionario allí. El número de filas que pone en ese búfer se basa en el tamaño máximo de fila. Digamos que su consulta arroja 4 columnas de varchar. Si el tamaño de las columnas es 100 y debe ser 10, Oracle ajustará 10 veces menos filas en cada extracción de lo que podría hacerlo con las definiciones de columnas del tamaño correcto. Esto hace que los bloques se vuelvan a leer innecesariamente. Fuerza más tráfico de red, más viajes redondos.

En Oracle puede cambiar el tamaño del búfer con SET ARRAYSIZE. Pruébelo alguna vez, haga una consulta con un tamaño y luego vuelva a hacerlo con el 10% del espacio. Verá que las lecturas aumentan, los viajes de red aumentan y el rendimiento baja. Hacer columnas demasiado grandes es como hacer que ese buffer sea demasiado pequeño.

Pero la verdadera razón para columnas de tamaño preciso es la integridad de los datos. Guardas cosas malas. Eso es tan importante como el rendimiento.

Recuerde:

• Nunca es demasiado pronto para diseñar para rendimiento
• 99% de lo que usted dice que volver, se quiere no
• Es mucho más fácil, mejor y más barato para hacer algo bien el primer tiempo .

Answer 7

mayoría de las otras respuestas aquí se centran en el hecho de que VARCHAR se almacena de una manera de longitud variable, por lo que almacena el número de bytes de la cadena que introduzca en una fila dada, no la longitud máxima del campo .

Pero durante las consultas, hay algunas circunstancias en las que MySQL convierte un VARCHAR en un CHAR - y, por lo tanto, el tamaño va hasta la longitud máxima. Esto sucede, por ejemplo, cuando MySQL crea una tabla temporal durante algunas operaciones JOIN u ORDER BY GROUP BY.

Decir todos los casos en los que esto sería complicado es complicado, ya que depende de cómo trate el optimizador la consulta, depende de la estructura de tabla e índices que defina, depende del tipo de consulta e incluso depende en la versión de MySQL porque el optimizador se mejora con cada versión.

La respuesta corta es sí, se puede hacer una diferencia si utiliza VARCHAR (255) o VARCHAR (30). Así que defina la longitud máxima de la columna de acuerdo con lo que necesita, no una longitud "grande" como 255 por el bien de la tradición.