Antes de encarar una tarea de indexación de tablas es fundamental
tener en cuenta lo siguiente:
o
A favor:
mejoraremos los tiempos de respuesta a consultas evitando costosos
escaneos, prolongados lockeos, etc. Es decir, será una acción fundamental para
lograr un sistema más ágil y performante.
o
En contra: Las operaciones de insert/update/delete
tendrán una mayor contención (demora), debido a que el motor deberá actualizar,
además de los datos de las tablas, los correspondientes a los índices que la
mismas contengan.
Hemos aprendido que los índices tienen “pros” y “cons” es hora entonces pensar en:
ü ¿Qué
características tiene el tipo de sistema sobre el cual voy a trabajar?
Aquí las respuestas pueden ser tres:
o
Transaccional (oltp): son ambientes con
operaciones de ABM constantes que en general no han de beneficiarse con
indexaciones. Por el contrario, serán más lentos cuando más índices existan.
o
De consultas (olap): al contrario de los
sistemas transaccionales, permiten indexar s/necesidad sin preocuparse por
posibles problemas de contención que pudiesen provocar los índices. Por lo general
este tipo de sistemas son réplicas de sistemas transaccionales o bien concebidos
bajo estructuras de datos desnormalizadas que son actualizadas por batch.
o Mixtos:
son sistemas transaccionales que a la vez proveen consultas. Los mismos
requieren de un especial equilibrio a la hora de ser indexados. Se trata de
sistemas cuyos índices deben proveer la performance necesaria sin dañar la transaccionalidad.
Se trata del tipo de sistemas donde con mayor equilibrio debemos trabajar.
ü ¿Qué
frecuencia de ejecución y en qué horario se ejecutará el proceso sobre el cual
estoy trabajando?
o
Frecuencia: si el proceso se ejecuta como
parte de un batch una vez al día tal vez no merezca la pena indexar la tabla si
su tiempo de respuesta es aceptable, (ejemplo un batch nocturno). Si por el contrario es un proceso que se
ejecuta frecuentemente habrá que trabajar con mayor fuerza en indexación sobre
el mismo, (ejemplo una consulta de saldo frecuente).
o
Horario: si el proceso es ejecutado en
horario de baja concurrencia podremos trazar una analogía con respecto al
proceso que es ejecutado con poca frecuencia, es decir, no valdrá la pena tal
vez emplear tantos índices. Si por el contrario es ejecutado en un horario de
mucha concurrencia hemos de trabajar fuertemente en indexación.
Aquí la regla es, a mayor concurrencia, mayor
necesidad de liberar rápidamente una tabla, por lo tanto, mayor necesidad de velocidad
a la hora de resolver una consulta.
ü ¿Hay
ya creado sobre la tabla un índice que pueda ser utilizado por mi proceso?
o
Es fundamental tener una visión global como la
que estamos proponiendo en este repaso previo antes de crear un índice. Si hay
un índice ya credo sobre la tabla podemos aprovechar el mismo adaptando nuestra
query o eventualmente modificando su estructura, midiendo antes el impacto sobre
todo el ecosistema de procesos del sistema que utilizan el índice. La idea es
no duplicar índices.
ü ¿Es
el campo por el cual quiero indexar lo suficientemente selectivo?
o
La “selectividad” de un campo es una métrica básica
que nos permitirá saber si el índice será tenido en cuenta o no por el optimizer
a la hora de crear un plan de ejecución. Si un índice esta creado sobre un
campo selectivo, por ejemplo, un valor numérico incremental, será tenido en
cuenta por el optimizer. De lo contrario, si es definido sobre un campo poco selectivo,
no será tenido en cuenta, (por ejemplo, un índice sobre un campo que identifique
el género de las personas).
ü ¿Cuál
es la cantidad de registros que tiene la tabla a indexar?
o
Debemos tener en consideración que el optimizer
elegirá utilizar el índice que hayamos creado si la tabla tiene una cantidad de
registros que así lo amerite, de lo contrario es muy probable que prefiera
hacer un scan de la misma. Como regla que yo empleo, ninguna tabla paramétrica que
tenga menos de 100 registros merece ser indexada. Los invito a dar forma a vuestra
propia regla generando índices y estudiando en el plan de ejecución si son o no
utilizados.
ü ¿Cuáles
campos de una query deberían ser indexados?
o
En principio aquellos campos que formen parte de
queries que vayan a ser validados luego de las siguientes cláusulas:
-
Where
-
Joins
-
Group By
-
Having
-
Order By
o
También sería apropiado incluir los campos que
formen parten del Select de una query cuya frecuencia de utilización e
importancia amerite la creación de un “índices cubierto”.
ü ¿Sobre
qué tipo de campos es conveniente indexar?
La efectividad de un índice será mayor cuando más
“chico” sea el campo, es decir cuanto menor sea su peso en bytes.
o
Debemos pues privilegiar los campos numéricos
por sobre el resto, siempre buscando el campo de menor peso dentro de este
grupo. Ejemplo un tinyint por sobre un integer o un decimal.
o Luego, en orden de efectividad, hemos de
considerar los campos de tipo fecha.
o
Por último, los campos de tipo alfanumérico o
char, lo cuales ofrecen el menor nivel de efectividad a la hora de ser
indexados.
