Reorganización de índices para mejorar el rendimiento en una tabla de gran tamaño

Depende de en qué "rango" están buscando tus consultas. ¿Están buscando en un rango por ID? ¿Están buscando en un rango de valores de "Nombre"? ¿Qué tan grande es el rango?

Ten en cuenta que una columna de identidad como "ID" es más o menos un valor que aumenta de forma monótona. Si agrupas una tabla por ID, entonces todas las inserciones tienden a ocurrir al "final" de la cadena de páginas, o más específicamente en un extensión. Esto es cierto para un índice no agrupado que está liderado por la columna de ID, con contendencia al final de la cadena. Tu pregunta sobre "Mejor rendimiento" depende de qué estás midiendo en términos de rendimiento. ¿Eliminaciones masivas? ¿Cargas masivas? ¿Consultas específicas? ¿Criterios de búsqueda específicos? Todo depende. Si nada más, prueba y mide de ambas formas. Así no habrá suposiciones de alguien como yo que no sabe nada sobre tus datos, aplicaciones o patrones de procesamiento empresarial.

Hola Kevin,

Lamento mucho haber proporcionado información incompleta. También vamos a eliminar la columna de estado junto con la columna de ID. Por lo tanto, nos quedaremos solo con tres columnas que son Nombre, Clase y Nombre de Grupo. El índice se creará en estas tres columnas.

Espero que, en este punto, nuestro objetivo sea verificar si la creación de un índice agrupado en estas tres columnas produce un mejor rendimiento que la creación de un índice no agrupado. Mi preocupación es que, dado que se eliminará la columna de ID, el índice agrupado no sea efectivo y pueda afectar las consultas de rango.

Por favor, házmelo saber si mi comprensión es correcta y dime la estrategia de índice correcta.

Muchas gracias de antemano.

Saludos

ADNAN

No está claro en absoluto lo que estás tratando de lograr aquí porque tus sugerencias clave no tienen sentido cuando se leen juntas. Indicas una regla de negocio de unicidad en 4 columnas:

nuestras necesidades comerciales indican que no deberíamos permitir dos filas con el mismo Nombre, Clase, Nombre de Grupo y Estado

sin embargo, describes una estrategia que implica un índice único en 3 columnas:

estamos pensando en crear índice no agrupado o índice no agrupado único en estas tres columnas (Nombre, Clase y Nombre de Grupo)

Necesitas decidir cuál es tu clave natural en realidad. Si "Estado" es parte de la clave, estoy seguro de que tu aplicación considera ese hecho y no actualizaría un valor de clave, sino que simplemente insertaría una fila "única" diferente (duplicada solo si tu clave NO incluye "Estado"). No estoy seguro de por qué necesitas una columna de identidad en la clave a menos que la estés usando como una clave artificial o como un criterio de búsqueda.

Tu descripción de una "actualización" por parte de la aplicación suena más como una inserción separada, por lo que sospecho que "Estado" se considera parte de la clave y los valores de clave no deberían actualizarse. Tal vez tu solución sea tan simple como eliminar "Estado" de la definición de clave principal de la tabla. De lo contrario, tendría sentido que existieran dos registros, uno para "insertado" y otro para "actualizado".

Sobre Agrupado vs No Agrupado: la razón principal para un índice agrupado es que deseas una fila físicamente junto a otra. Si estás buscando en esta tabla basándote en una búsqueda de clave parcial o deseas el orden de los resultados por la clave, entonces el índice agrupado es una ventaja.