Tema 7: Puesta a punto y administración de base de datosIng. Marco Antonio Condarco Mirabal

Base de Datos IIIndices 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.

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.