Indices SQL SERVER - II

Este post es la continuación del previo post con el mismo título, jeje.
Recordemos:
Para qué sirven los índices?
Para mejorar la performance de una consulta.
Cómo es que un índice puede mejorar la performance de una consulta?
Fácil, los índices ordenan los registros de una tabla, esta ordenación finalmente permite acceder a los registros de manera más rápida, pues se llega más rápido al lugar donde se encuentra la información requerida, ya que estos índices funcionan de similar manera a los índices de un libro (lo he dicho 20 veces en el post anterior).
La recomendación es usar índices sobre las columnas que participan en la cláusula WHERE de una consulta.
Una tabla puede tener un índice clusterado y 249 índices no clusterados. Osea, en total 250 índices.
Recuerda que un índice puede estar conformado por varias columnas.
Hay dos tipos de índices:
Clusterados.- Ordenan físicamente las filas de una tabla.
Por lo tanto sólo puede haber un índice clusterado por tabla.
Normalmente, el índice clusterado termina siendo la columna con la clave primaria, pues por defecto la columna con clave primaria crea un índice clusterado sobre sí, determinando de esta manera el ordenamiento de dicha tabla (si es que no se ha declarado previamente otra columna con índice clusterado ... claro).
Si Ud. desea crear una tabla cuya clave principal no tenga el índice clusterado, debe añadirle el comando NONCLUSTERED.
De igual manera debe especificar cuál será la columna CLUSTERED... vea:
CREATE TABLE Employee
(
EmployeeID INT PRIMARY KEY NONCLUSTERED,
FirstName VARCHAR(100),
LastName VARCHAR(100),
SSN VARCHAR(8) UNIQUE CLUSTERED
)
Como observa: la columna EmployeeID tiene un índice no clusterado y, la columna SSN ha sido designada como índice clusterado.
Para confirmar, ejecutamos:
SP_HELPINDEX Employee
Pero, qué gano si a la clave primaria le pongo NONCLUSTERED?
Para que entiendas el beneficio de un índice NONCLUSTERED, revisa este concepto:
No Clusterados.- Funcionan similar a los índices clusterados, mejoran la performance de las consultas ya que buscan los registros siguiendo un orden en las filas.
La diferencia es que estos índices no clusterados no determinan el orden físico de las filas en una tabla.
Mas bien, lo que hacen es crear una pila de información lejos de la tabla, donde la información se organiza en base a punteros hacia los identificadores de cada fila... llamados RID (Row Id).
Y cuando se hace una consulta a dicha tabla, se accede a esta pila de información para obtener las filas necesarias.
Entenderás ahora por qué las búsquedas en base a índices clusterados es más rápida:
Porque se busca directamente en la tabla.Pero bueno, no todo es color de rosa, algo malo deben tener estos índices cierto?
Tienes razón. Hablemos de ello.
Los índices son excelentes cuando se trata de consultar datos... osea en operaciones con el comando SELECT.
Lo triste viene con las operaciones de INSERT o UPDATE de una fila... las filas buscarán reordenarse... pues la fila insertada/editada querrá ocupar su nuevo lugar... y las demás filas deberán cederle un lugar... esto provocará que toda la tabla se re-ordene y por consecuencia, genere un retraso en la culminación de la consulta.
Esta pérdida de performance nos conlleva a analizar muy bien cuáles son los índices realmente necesarios que necesita la tabla, ya que a mayor cantidad de índices: mayor retraso en la finalización de la consulta.
Díganme que no es cierto.