1. Tema 7: Puesta a punto y administración de base de datos
Ing. Marco Antonio Condarco Mirabal
Base de Datos II
Indices en SQL Server (Discriminando la versión)
Este es un post introductorio referente a Indices, no veremos un nivel avanzado del tema
esta vez, la intencion es que podamos tener una mejor vision de lo que significan los
indices en SQL Server, a fin de poder usarlos correctamente en un futuro.
Entonces lo primero que nos preguntariamos Qué es un indice?
Una analogia que siempre se utiliza es el Indice de un Diccionario (No diccionario de datos,
sino el que usamos para buscar significados de palabras), su funcion principal es darnos una
referencia rapida de como encontrar un grupo de palabras, ese grupo se ordena por orden
alfabetico en este caso, si tenemos claro como funciona un Indice a ese nivel entonces
seguimos.
Ok tenemos claro el Indice del Diccionario, ahora debemos saber de que forma SQL Server
almacena los datos en el disco duro, y los almacena utilizando Pages (paginas) de un
tamaño de 8kb c/u, entonces nuestra información se almacena en múltiples paginas ya que
en una tabla de 1Mb existen 128 paginas (16 extends) eso quiere decir que al realizar una
consulta a la tabla (select * from tabla) para recuperar la información a mostrar, debe
buscar entre todas esas paginas que información pertenece a la tabla invocada y separarlas
de los datos que pertenecen a otros objetos.
Volviendo al ejemplo del Diccionario de significado, si buscamos la palabra zona
pasaremos por la A, B, C .. hasta llegar a Z y luego buscar la palabra zona; o iremos
directamente al grupo de la Z y luego buscamos zona.
Una tabla sin indices buscara sus registros en todas las paginas que pueda, podrá insertar
rápidamente la información, pero recuperar los resultados de una consulta tomara un
tiempo prudencial dependiendo la cantidad de registros, paginas, entre otros factores como
trafico de red, velocidad del disco, etc.
Una tabla sin indices se conoce como Heap o en nuestro idioma montón, ya que todo esta
formado sin un orden y tienes que buscar entre todo ese montón tu información o datos.
Los índices son objetos de la bases de datos, cuya función es optimizar el acceso a datos. A
medida que las tablas se van haciendo más grandes y se desea hacer consultar sobre estas
tablas, los índices son indispensables.
Internamente un índice normal es una estructura de árbol, que cuenta con una página
principal y luego esta con paginas hijas, que a su vez tiene más paginas hijas hasta llegar a
la pagina final del índice (leaf level).
La clave del índice está repartida en las páginas del índice, de modo tal que la búsqueda se
haga leyendo la menor cantidad posible de datos.
2. En el caso que la tabla tenga indices, ya sean Cluster o Non Cluster, la información podrá
retornar de forma mas eficiente, ahora la pregunta es, en donde van los indices. Los indices
van en la tabla como un objeto adicional, pero hacen referencia a un campo primario, o a
otros campos de la tabla, si tenemos un campo Id_Tabla que es Primary Key (Entendemos
esto como el campo principal de la tabla) SQL Server creara automáticamente un indice
Cluster haciendo referencia al campo Id_Tabla. En el caso tenemos un campo que no es
Primary Key, como fec_vta al crear un indice para un campo que no es PK, se le debe crear
como Non-cluster.
Ahora bien, entonces porque no siempre usar índices clustered? Bueno, en primer lugar,
lamentablemente solo puede haber 1 solo índice clustered por tabla. La razón es muy
sencilla y lógica: Los registros de la tabla físicamente son las paginas leaf-level del índice
clustered. Los datos de la tabla esta ordenados según el índice. Y obviamente una tabla no
puede simultáneamente estar físicamente ordenada de 2 maneras diferentes.
Por lo tanto, en tablas grandes y muy consultadas, tenemos que ser cuidadosos y analizar a
que campos vamos a seleccionar para ser llaves del índice clustered. Tenemos 1 solo índice
de este tipo por tabla, no hay que desperdiciarlo!!!
Este último punto es importante para saber en qué situaciones y para que campos se debe
utilizar un clustered index o un non-clustered.
Imaginemos el Diccionario y que en el Indice no existan grupos de letras, sino un juego de
letras por ejemplo Ab, Ac, Az; Bl, etc etc; tomara un poco mas de tiempo buscar el grupo
adecuado en el indice pero la búsqueda en el diccionario sera mas rápido que buscar en toda
la letra Z. Pero que pasa si el indice tiene un numero para cada palabra en el diccionario, al
final solo buscaríamos prácticamente en todo el diccionario, con esto lo que quiero dejar en
claro que los indices son buena opción para resolver consultas, pero no se trata de poner
muchos indices por ponerlo, se debe tener algunas recomendaciones, por ejemplo que
sentido tendría poner como indice al campo Observaciones, si nunca en los querys haremos
un filtro o un where por ese campo.
Para colocar indices debemos primero evaluar los querys que utilizamos, ver que filtros o
match existen en los Join, ya que SQL Server utilizara esos campos como búsqueda inicial,
entonces es en ellos donde debemos analizar y probar si resulta o no crear un indice.
