Hacer que una consulta trabaje es una cosa, pero obtener una consulta que trabaje lo m�s r�pidamente es otra muy diferente. Podemos acelerar nuestras consultas de dos maneras b�sicamente, una de ellas es afinando nuestro servidor para que responda lo mejor posible, y la otra, que es la que trataremos en este art�culo, es haciendo uso de los �ndices de una manera inteligente.
Los �ndices son usados para encontrar r�pidamente los registros que tengan un determinado valor en alguna de sus columnas. Sin un �ndice, MySQL tiene que iniciar con el primer registro y leer a trav�s de toda la tabla para encontrar los registros relevantes. A�n en tablas peque�as, de unos 1000 registros, es por lo menos 100 veces m�s r�pido leer los datos usando un �ndice, que haciendo una lectura secuencial.
Cuando MySQL trata de responder una consulta, examina una variedad de estad�sticas acerca de nuestros datos y decide como buscar los datos que deseamos de la manera m�s r�pida. Sin embargo, como se acaba de mencionar, cuando en una tabla no existen �ndices en los cuales pueda auxiliarse MySQL para resolver una consulta se tendr�n que leer todos los registros de la tabla de manera secuencial. Esto es com�nmente llamado un "escaneo completo de una tabla", y es muchas veces algo que se debe evitar.
En particular, debemos evitar las escaneos completos de tablas por las siguientes razones:
- Sobrecarga de CPU. El proceso de checar cada uno de los registros en una tabla es insignificante cuando se tienen pocos datos, pero puede convertirse en un problema a medida que va aumentando la cantidad de registros en nuestra tabla. Existe una relaci�n proporcional entre el n�mero de registros que tiene una tabla y la cantidad de tiempo que le toma a MySQL revisarla completamente.
- Concurrencia. Mientras MySQL est� leyendo los datos de una tabla, �ste la bloquea, de tal manera que nadie m�s puede escribir en ella, aunque si pueden leerla. Cuando MySQL est� actualizando o eliminando filas de una tabla, �ste la bloquea, y por lo tanto nadie puede al menos leerla.
- Sobrecarga de disco. En una tabla muy grande, un escaneo completo consume una gran cantidad de entrada/salida en el disco. Esto puede alentar siginificativamente nuestro servidor de bases de datos, especialmente si tenemos un disco IDE algo antiguo.
En resumen, lo mejor es tratar de que los escaneos completos de tablas sean m�nimos -- especialmente si nuestra aplicaci�n necesita escalabilidad en tama�o, n�mero de usuarios, o ambos. Las versiones actuales de MySQL hacen distintas mejoras en cuanto a concurrencia, pero ese tema est� m�s all� de nuestra discusi�n.
Es en estos casos donde la indexaci�n puede ayudarnos. De manera simple, un �ndice le permite a MySQL determinar si un valor dado coincide con cualquier fila en una tabla.
Cuando indexamos una columna en particular, MySQL crea otra estructura de datos (un �ndice) que usa para almacenar informaci�n extra acerca de los valores en la columna indexada. Los valores indexados son llamados frecuentemente claves. Aunque esta es la manera simple de explicar los �ndices, realmente es un poco m�s complejo, ya que MySQL almacena todas las claves del �ndice en una estructura de datos de �rbol. Esta estructura de datos de �rbol le permite a MySQL encontrar claves muy r�pidamente.
Cuando MySQL encuentre que hay un �ndice en una columna, lo usar� en vez de hacer un escaneo completo de la tabla. Esto reduce de manera imporante los tiempos de CPU y las operaciones de entrada/salida en disco, a su vez que se mejora la concurrencia porque MySQL bloquear� la tabla �nicamente para obtener las filas que necesite (en base a lo que encontr� en el �ndice). Cuando tenemos grandes cantidades de datos en nuestras tablas, la mejora en la obtenci�n de los datos puede ser muy significativa.