ÍNDICES

ING. HERNÁN NARANJO

Índices
Los índices en una base de datos, constituyen una parte fundamental del correcto diseño, y muy
a menudo son claramente subestimados. Básicamente, su propósito es permitir que las
operaciones de acceso a datos se realicen de la forma más óptima posible.

Si bien existen varios tipos de índices, este post apunta a cubrir los dos tipos más comunes:

Índices Clustered

Índices NonClustered
Índices Clustered
Un índice Clustered es aquel que define
el ordenamiento físico de los datos en
una tabla. Como una tabla puede tener
un único criterio de ordenamiento, sólo
puede existir un índice Clustered por
tabla, y podría ilustrarse de la siguiente
manera:
Índices Clustered
Si bien típicamente el índice Clustered de una tabla se corresponde con su clave
primaria, esto no es estrictamente necesario. A modo de ejemplo, si una tabla
contiene una columna de tipo datetime sobre la cual se ejecutan
frecuentemente consultas por rango de fecha, sería conveniente que el índice
Clustered fuera definido sobre dicha columna.
Índices Clustered
¿En qué casos es conveniente utilizar un índice Clustered?

Cuando se trata de columnas que son muy comúnmente agrupadas con GROUP
BY u ordenadas con ORDER BY

Cuando se tratan de columnas de tipo IDENTITY o UNIQUEIDENTIFIER, para

prevenir la fragmentación de páginas.
Índices NonClustered
Un índice NonClustered constituye una lista de marcadores ordenados en base al criterio
que deseemos definir.

Cada entrada, está compuesta de los siguientes datos:

Los campos que componen la clave del índice (Index Key)

Un marcador que apunta al registro correspondiente (RID)

A partir de SQL Server 2008, podemos tener hasta un máximo de 999 índices de este tipo en
una tabla, los cuales pueden estar compuestos de un máximo de 16 columnas en su Index
Key, y el largo total de dicho Index Key no puede superar los 900 bytes.
Índices NonClustered
Escenario de uso de índice NonClustered

Contamos con una tabla en donde se

almacenan el Nombre y Apellido de nuestros
clientes. La tabla, a priori, no tiene un orden
determinado, pero es frecuente que se
realicen búsquedas por apellido exacto, sobre
dicha tabla, con una sentencia SQL similar a
la siguiente:
Índices NonClustered
Alternativa #1:
Permitir que SQL Server localice el apellido
buscado realizando una búsqueda sobre la
tabla completa, tal como la misma se
encuentra ordenada.
En este caso, SQL Server decidirá utilizar el
siguiente plan de ejecución para resolver la
consulta:
 Índices NonClustered
Alternativa #2:
Crear un índice que permita a SQL Server localizar más rápidamente un apellido, y así evitar realizar
una búsqueda sobre la tabla completa.
En este caso decidiremos crear un índice que contenga únicamente el campo “Apellido”, ya que sobre
este campo se realizan típicamente las búsquedas. Un índice de este tipo, se conoce como índice
NonClustered, y tiene una apariencia similar a la siguiente:
Índices NonClustered
A partir de la creación del índice antedicho, el plan de ejecución cambiará drásticamente,
dejando de ser una lectura completa de la tabla (Full Scan), para pasar a ser un búsqueda sobre
un índice (Index Seek), redundando así en la utilización de una operación óptima.