El optimizador de consultas puede usar un índice, agrupado o no agrupado, si y solo si se filtra la clave más a la izquierda en el índice. Entonces, si define un índice en las columnas (A, B, C), una condición DONDE en [email protected] , en [email protected] o en [email protected] AND [email protected] no aprovechará completamente el índice (ver nota). Esto se aplica también a las condiciones de unión. Cualquier filtro WHERE que incluya A considerará el índice:[email protected] o [email protected] AND [email protected] o [email protected] AND [email protected] o [email protected] AND [email protected] AND [email protected] .
Entonces, en su ejemplo, si crea el índice agrupado en part_no como la tecla más a la izquierda, luego una consulta que busca un part_id específico no use el índice y debe existir un índice no agrupado separado en part-id .
Ahora, sobre la cuestión de cuál de los muchos índices debería ser el agrupado uno. Si tiene varios patrones de consulta que tienen aproximadamente la misma importancia y frecuencia y se contradicen entre sí en cuanto a las claves necesarias (por ejemplo, consultas frecuentes de cualquiera part_no o part_id ) entonces se toman en consideración otros factores:
- ancho :la clave de índice agrupado se utiliza como clave de búsqueda por todos otros índices no agrupados. Entonces, si elige una clave ancha (por ejemplo, dos columnas de uniidentificador), entonces está ampliando todos los demás índices, consumiendo más espacio, generando más IO y ralentizando todo. Entonces, entre claves igualmente buenas desde un punto de vista de lectura, elija la más estrecha como agrupada y haga que las más anchas no estén agrupadas.
- contienda :si tiene patrones específicos de inserción y eliminación, intente separarlos físicamente para que se produzcan en diferentes partes del índice agrupado. P.ej. si la tabla actúa como una cola con todas las inserciones en un extremo lógico y todas las eliminaciones en el otro extremo lógico, intente diseñar el índice agrupado para que el orden físico coincida con este orden lógico (p. ej., orden en cola).
- partición :si la tabla es muy grande y planea implementar la partición, la clave de partición debe ser el índice agrupado. Un ejemplo típico son los datos históricos que se archivan utilizando un esquema de partición de ventana deslizante. Aunque las entidades tienen una clave principal lógica como 'entity_id', el índice agrupado se realiza mediante una columna de fecha y hora que también se usa para la función de partición.
- estabilidad :una clave que cambia con frecuencia no es una buena candidata para una clave agrupada, ya que cada una actualiza el valor de la clave agrupada y fuerza todas índices no agrupados para actualizar la clave de búsqueda que almacenan. Como una actualización de una clave agrupada probablemente también reubicará el registro en una página diferente, puede causar fragmentación en el índice agrupado.
Nota:no totalmente aproveche, ya que a veces el motor elegirá un índice no agrupado para escanear en lugar del índice agrupado simplemente porque es más estrecho y, por lo tanto, tiene menos páginas para escanear. En mi ejemplo, si tiene un índice en (A, B, C) y un filtro DONDE en [email protected] y los proyectos de consulta C , es probable que se utilice el índice, pero no como una búsqueda, sino como un escaneo, porque sigue siendo más rápido que un escaneo agrupado completo (menos páginas).
