sql >> Base de Datos >  >> RDS >> Sqlserver

Cree más de un índice no agrupado en la misma columna en SQL Server

Las palabras son bastante lógicas y las aprenderás con bastante rapidez. :)

En términos sencillos, BUSCAR implica buscar ubicaciones precisas para los registros, que es lo que hace SQL Server cuando la columna en la que está buscando está indexada y su filtro (la condición DONDE) es lo suficientemente preciso.

SCAN significa un mayor rango de filas donde el planificador de ejecución de consultas estima que es más rápido obtener un rango completo en lugar de buscar individualmente cada valor.

Y sí, puede tener varios índices en el mismo campo y, a veces, puede ser una muy buena idea. Juegue con los índices y use el planificador de ejecución de consultas para determinar qué sucede (acceso directo en SSMS:Ctrl + M). Incluso puede ejecutar dos versiones de la misma consulta y el planificador de ejecución le mostrará fácilmente cuántos recursos y tiempo consume cada una, lo que facilita bastante la optimización.

Pero para ampliar esto un poco, supongamos que tiene una tabla de direcciones como esta, y tiene más de mil millones de registros:

CREATE TABLE ADDRESS 
  (ADDRESS_ID INT -- CLUSTERED primary key ADRESS_PK_IDX
  , PERSON_ID INT -- FOREIGN KEY, NONCLUSTERED INDEX ADDRESS_PERSON_IDX
  , CITY VARCHAR(256)
  , MARKED_FOR_CHECKUP BIT
  , **+n^10 different other columns...**)

Ahora, si desea encontrar toda la información de la dirección de la persona 12345, el índice de PERSON_ID es perfecto. Dado que la tabla tiene muchos otros datos en la misma fila, sería ineficiente y ocuparía mucho espacio crear un índice no agrupado para cubrir todas las demás columnas, así como PERSON_ID. En este caso, SQL Server ejecutará un índice SEEK en el índice de PERSON_ID, luego lo usará para realizar una búsqueda de clave en el índice agrupado en ADDRESS_ID y desde allí devolverá todos los datos en todas las demás columnas en esa misma fila.

Sin embargo, digamos que desea buscar a todas las personas de una ciudad, pero no necesita otra información de dirección. Esta vez, la forma más efectiva sería crear un índice en CITY y usar la opción INCLUDE para cubrir PERSON_ID también. De esa manera, una sola búsqueda/escaneo de índice devolvería toda la información que necesita sin la necesidad de recurrir a verificar el índice CLUSTERED para los datos PERSON_ID en la misma fila.

Ahora, digamos que ambas consultas son obligatorias pero aún bastante pesadas debido a los mil millones de registros. Pero hay una consulta especial que debe ser muy, muy rápida. Esa consulta quiere todas las personas en las direcciones que se han MARCADO_PARA_CHEQUEO y que deben vivir en Nueva York (ignore lo que signifique el chequeo, eso no importa). Ahora es posible que desee crear un tercer índice filtrado en MARKED_FOR_CHECKUP y CITY, con INCLUDE cubriendo PERSON_ID, y con un filtro que diga CITY ='New York' y MARKED_FOR_CHECKUP =1. Este índice sería increíblemente rápido, ya que solo cubre consultas que satisfacen esas condiciones exactas y, por lo tanto, tienen una fracción de los datos para analizar en comparación con los otros índices.

(Descargo de responsabilidad aquí, tenga en cuenta que el planificador de ejecución de consultas no es estúpido, puede usar varios índices no agrupados juntos para producir los resultados correctos, por lo que los ejemplos anteriores pueden no ser los mejores disponibles, ya que es muy difícil imaginar cuándo necesitaría 3 índices diferentes que cubren la misma columna, pero estoy seguro de que entiendes la idea).

Los tipos de índice, sus columnas, columnas incluidas, órdenes de clasificación, filtros, etc. dependen completamente de la situación. Deberá crear índices de cobertura para satisfacer varios tipos diferentes de consultas, así como índices personalizados creados específicamente para consultas singulares e importantes. Cada índice ocupa espacio en el HDD, por lo que crear índices inútiles es un desperdicio y requiere un mantenimiento adicional cada vez que cambia el modelo de datos, y pierde tiempo en las operaciones de desfragmentación y actualización de estadísticas... por lo que no desea colocar un índice en todo. tampoco.

Experimente, aprenda y descubra cuál funciona mejor para sus necesidades.