Deberías DEFINITIVAMENTE introduce un sustituto INT IDENTITY() ¡clave principal! INT ya le brinda potencialmente hasta 2 mil millones de filas, ¿no es eso suficiente?
Esta clave principal / clave agrupada en SQL Server tendrá un tamaño de hasta 64 bytes (en lugar de 4, para un INT), lo que hará que su índice agrupado Y todo su índice no agrupado se hinche más allá del reconocimiento. La clave de agrupamiento completa (todas sus 8 columnas) se incluirá en cada página de cada índice no agrupado en esa tabla, lo que seguramente desperdiciará mucho espacio.
Entonces, en cualquier tabla de índice dada, tendría hasta 16 veces más entradas con una clave agrupada INT sustituta, lo que significa muchas menos E/S, mucho menos tiempo perdido leyendo páginas de índice.
E imagínese intentar establecer una relación de clave externa con esa tabla... cualquier tabla secundaria tendría que tener todas las 8 columnas de su clave principal como columnas de clave externa, y especifique las 8 columnas en cada combinación:¡qué pesadilla!
Con 78 millones de filas, incluso cambiando la clave de agrupación a INT IDENTITY le ahorrará hasta 60 bytes por fila; eso por sí solo sería hasta 4 GB de espacio en disco (y uso de RAM en su servidor). Y eso ni siquiera es empezar a calcular los ahorros en los índices no agrupados.......
Y, por supuesto, sí, también cambiaría VARCHAR(10) a INT o BIGINT; si es un número, haga que el tipo de campo sea numérico; no tiene sentido dejarlo en VARCHAR(10), en realidad. Pero eso por sí solo no va a hacer una gran diferencia en términos de velocidad o rendimiento, solo hace que trabajar con los datos sea mucho más fácil (no es necesario tener que recurrir siempre a tipos numéricos cuando, por ejemplo, se comparan valores, etc.).
Marc
