Duplicar posibles:
Importance of varchar length in MySQL table¿Importa el límite de tamaño VARCHAR?
Al utilizar VARCHAR (suponiendo que este es el tipo de datos correcto para una cadena corta) ¿El tamaño importa? Si lo configuro en 20 caracteres, ¿ocupará menos espacio o será más rápido que 255 caracteres?
En general, para un campo VARCHAR, la cantidad de datos almacenados en cada campo determina su huella en el disco en lugar del tamaño máximo (a diferencia de un campo CHAR que siempre tiene la misma huella).
Existe un límite superior en la información total almacenada en todos los campos de un índice de 900 bytes (900 byte index size limit in character length).
Cuanto más grande sea el campo, más probabilidades habrá de que la gente intente utilizarlo para fines distintos a los que pretendía, y cuanto mayor sea el espacio de la pantalla requerido para mostrar el valor, es una buena práctica intentar elegir el derecho tamaño, en lugar de asumir que si lo hace lo más grande posible le ahorrará tener que volver a visitar el diseño.
Si lo configura en 20, guardará solo los primeros 20 caracteres. Entonces sí, ocupará menos espacio que 255 caracteres :).
Esto no tendrá ningún efecto en el rendimiento. En este caso, la restricción simplemente ayuda a garantizar la integridad de los datos.
Puede tener un efecto masivo en el rendimiento. Si utiliza incluso una columna VarChar (o texto, u otra columna de ancho variable), MySQL utiliza un formato de fila de ancho dinámico. Entonces, para hacer un escaneo de tabla, será necesario que lea cada fila secuencialmente para encontrar el siguiente. La diferencia entre omitir unos pocos cientos de bytes y algunos miles de bytes (debido a múltiples VarChars demasiado largos) puede ser muy significativa (principalmente dependiendo de la estructura de la unidad subyacente y de los dispositivos de bloque). Pero, en resumen, puede soportar absolutamente el rendimiento (sobre todo para tablas grandes con GB de datos, sin embargo, lo notarás) ... – ircmaxell
Las diferencias reales son:
TINYTEXT y otros campos de texto se almacenan por separado de la fila en memoria dentro de MySQL montón, mientras que VARCHAR() campos se suman a 64k límite (para que pueda tener más de 64k en TINYTEXTs, mientras que no lo hará con VARCHAR).
TINYTEXT y otros campos 'blob-like' obligarán a la capa SQL (MySQL) a usar tablas temporales en disco siempre que se utilicen, mientras que VARCHAR seguirá ordenándose 'en la memoria' (aunque se convertirá en CHAR para todo el ancho).
InnoDB internamente realmente no le importa si es tinytext o varchar. Es muy fácil de verificar, crear dos tablas, una con VARCHAR (255), otra con TINYINT e insertar un registro en ambas. Ambos tomarán una sola página de 16k, mientras que si se usan páginas de desbordamiento, la tabla TINYTEXT debería aparecer como tomando al menos 32k en 'SHOW TABLE STATUS'.
Por lo general prefieren VARCHAR (255) - no causan demasiado de la fragmentación del montón de una hilera, y puede ser tratada como un objeto único en la memoria 64k dentro de MySQL. En InnoDB, las diferencias de tamaño son insignificantes.
El required storage space for VARCHAR es el siguiente:
VARCHAR(L),VARBINARY(L)-L+ 1 bytes si los valores de columna requieren 0 - 255 bytes,L+ 2 bytes si los valores pueden requerir más de 255 bytes
Por lo tanto, VARCHAR solo requiere el espacio para la cadena más uno o dos bytes adicionales para la longitud de la cadena.
Sí, es importante al indexar varias columnas.
Los prefijos pueden tener hasta 1000 bytes de longitud (767 bytes para tablas InnoDB). Tenga en cuenta que los límites del prefijo se miden en bytes, mientras que la longitud del prefijo en las sentencias CREATE TABLE se interpreta como el número de caracteres. Asegúrese de tener esto en cuenta al especificar una longitud de prefijo para una columna que usa un conjunto de caracteres de múltiples bytes.
fuente: http://dev.mysql.com/doc/refman/5.0/en/column-indexes.html
En una colación latin1, sólo se puede especificar hasta 3 columnas de varchar(255).
Si bien puede especificar un máximo de 50 columnas para varchar(20)
En forma directa, sin índice adecuado, se desaceleración velocidad de las consultas
En términos de almacenamiento, que no hace diferencia,
como varchar presentarse a las variable-length strings
En la documentación de MySQL: http://dev.mysql.com/doc/refman/5.0/en/char.html
Tiene una tabla que indica los bytes de un VARCHAR (4) (frente a un CHAR (4)).
Un VARCHAR simple (4) sin cadena, solo 1 byte. Entonces, un VARCHAR simple (255) sin cadena es de 1 byte. Un VARCHAR (4) con 'ab' es de 3 bytes, y un VARCHAR (255) con 'ab' es de 3 bytes. Es lo mismo, pero con el límite de longitud :)
Hay un gran comentario en el artículo mencionado anteriormente. "Hay un posible impacto en el rendimiento: en MySQL, las tablas temporales y MEMORY almacenan una columna VARCHAR como una columna de longitud fija, acolchada a su longitud máxima. Si diseña columnas VARCHAR mucho más grandes que el tamaño más grande que necesita, consumirá más memoria de la necesaria. Esto afecta la eficacia de la memoria caché, la velocidad de clasificación, etc. " – Riedsio