Es varchar (128) mejor que varchar (100)

Question

Pregunta rápida. ¿Importa desde el punto de almacenamiento de datos si usaré límites de campo decimal o hexadecimal (digamos 16,32,64 en vez de 10,20,50)?

Lo pregunto porque me pregunto si esto tendrá algo que ver con los clústeres en la unidad de disco duro?

Gracias!

Answer 1

VARCHAR (128) es mejor que VARCHAR (100) si necesita almacenar cadenas de más de 100 bytes.

De lo contrario, hay muy poco para elegir entre ellos; debe elegir el que mejor se ajuste a la longitud máxima de los datos que pueda necesitar almacenar. No podrá medir la diferencia de rendimiento entre ellos. Aparte de todo lo demás, el DBMS probablemente solo almacena los datos que envía, por lo que si su cadena promedio es, por ejemplo, 16 bytes, solo usará 16 (o, más probablemente, 17 - permitiendo 1 byte para almacenar la longitud) bytes en el disco . El tamaño más grande puede afectar el cálculo de cuántas filas pueden caber en una página, perjudicialmente. Por lo tanto, tiene sentido elegir el tamaño más pequeño que sea adecuado: no desperdicie, no quiera.

Por lo tanto, en resumen, existe una pequeña diferencia entre los dos en términos de rendimiento o uso del disco, y la alineación a los límites binarios convenientes realmente no hace la diferencia.

Answer 2

Sí, pero no es tan simple. A veces 128 puede ser mejor que 100 y, a veces, es al revés.

¿Qué está pasando? varchar solo asigna espacio según sea necesario, por lo que si almacena hello world en un varchar(100), ocupará exactamente la misma cantidad de espacio que en un varchar(128).

La pregunta es: si llena las filas, ¿alcanzará un límite/límite de "bloque" o no?

Las bases de datos almacenan sus datos en bloques. Estos tienen un tamaño fijo, por ejemplo 512 (este valor se puede configurar para algunas bases de datos). Entonces la pregunta es: ¿Cuántos bloques tiene que leer el DB para buscar cada fila? Las filas que abarcan varios bloques necesitarán más E/S, por lo que esto lo hará más lento.

Pero otra vez: Esto no depende del tamaño teórico máximo de las columnas sino de a) cuántas columnas tiene (cada columna necesita un poco de espacio incluso cuando está vacía o null), b) cuántos columnas de ancho fijo que tiene (number/decimal, char), y finalmente c) la cantidad de datos que tiene en columnas de variables.

Answer 3

Si fuera un C-Program, me gustaría dedicar un tiempo a pensar en eso también. Pero con una base de datos lo dejo al motor de DB.

Los programadores de DB dedicaron mucho tiempo a pensar en la mejor disposición de la memoria, así que simplemente diga a la base de datos lo que necesita y almacenará los datos de la manera que mejor se adapte al motor de DB (generalmente).

Si desea alinear sus datos, tendrá que exacto conocimiento de la organización interna de datos: ¿Cómo se almacena la cadena? Uno, dos o 4 bytes para almacenar la longitud? ¿Se almacena como secuencia de bytes simples o codificada en UTF-8 UTF-16 UTF-32? ¿El DB necesita bytes adicionales para identificar valores NULL o> MAXINT? Tal vez la secuencia se almacena como una secuencia de bytes terminada en NUL; luego, se necesita un byte más internamente.

También con VARCHAR no es necesario que la DB siempre asigne 100 (128) bytes para su cadena. Tal vez almacena solo un puntero a donde está el espacio para los datos reales.

Por lo tanto, le sugiero que use VARCHAR (100) si ese es su requisito. Si el DB decide alinearlo de alguna manera, también hay espacio para datos internos adicionales.

Otra manera: supongamos que utiliza VARCHAR (128) y todo se combina: el DB asigna 128 bytes para sus datos. Además, necesita 2 bytes más para almacenar la longitud real de la cadena - hace 130 bytes - y luego podría ser que el DB alinee los datos con el siguiente límite (digamos 32 bytes): los datos reales que se necesitan en el disco ahora son 160 bytes 8-}