php - ejemplos - django

¿Importa el límite de tamaño de VARCHAR?

Question

Posible duplicado:
Importancia de la longitud varchar en la tabla MySQL

Cuando se usa VARCHAR (asumiendo 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?

Answer 1

El espacio de almacenamiento requerido para 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.

Answer 2

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).

Hay un límite superior en el total de datos almacenados en todos los campos de un índice de 900 bytes ( límite de tamaño de índice de 900 bytes en longitud de caracteres ).

Cuanto más grande sea el campo, mayor será la probabilidad de que la gente intente usarlo para fines diferentes a los que usted pretendía, y cuanto mayor sea la cantidad de espacio real requerido para mostrar el valor, por lo que es una buena práctica tratar de elegir el tamaño correcto . en lugar de suponer que si lo hace lo más grande posible, le ahorrará tener que volver a visitar el diseño.

Answer 3

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 :)

Answer 4

Esto no tendrá ningún efecto en el rendimiento. En este caso, la restricción simplemente ayuda a garantizar la integridad de los datos.

Answer 5

Las diferencias reales son:

• TINYTEXT y otros campos de TEXTO se almacenan por separado de la fila en la memoria dentro del montón de MySQL, mientras que los campos VARCHAR () suman hasta el límite de 64k (por lo que puede tener más de 64k en TINYTEXTs, mientras que no lo hará con VARCHAR).

• TINYTEXT y otros campos ''similares a blobs'' obligarán a la capa SQL (MySQL) a usar tablas temporales en el disco siempre que se usen, mientras que VARCHAR todavía se ordenará ''en memoria'' (aunque se convertirá a CHAR para todo el ancho) .

• InnoDB internamente no importa si se trata de 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 mostrarse como al menos 32k en ''MOSTRAR ESTADO DE LA TABLA''.

Por lo general, prefiero VARCHAR (255): no causan demasiada fragmentación del montón para una fila, y pueden tratarse como un único objeto de 64k en la memoria dentro de MySQL. En InnoDB las diferencias de tamaño son despreciables.

Answer 6

Si lo establece en 20, solo se guardarán los primeros 20 caracteres. Entonces sí, ocupará menos espacio que 255 caracteres :).

Answer 7

This respuesta debería ayudarte.

Answer 8

Sí, es importante cuando indexas múltiples columnas.

Los prefijos pueden tener una longitud de hasta 1000 bytes (767 bytes para las tablas InnoDB). Tenga en cuenta que los límites de prefijo se miden en bytes, mientras que la longitud del prefijo en las sentencias CREATE TABLE se interpreta como 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 clasificación latin1, solo puede especificar hasta 3 columnas de varchar(255) .
Si bien puede especificar hasta 50 columnas para varchar(20)

En forma directa, sin el índice adecuado, disminuirá la velocidad de consulta

En términos de almacenamiento, no hace diferencia,
como soporte varchar para variable-length strings