Rendimiento en MySQL II

04 jun. 2008
Siguiendo un poco con la primera parte del artículo sobre Rendimiento en MySQL, quisiera añadir algunas sugerencias.

¿Cómo decidir qué índices configurar?
Hay sentencias SQL que se usan mucho más que otras, así como sentencias SQL más pesadas que otras.

Por tanto, comenzaremos siempre por las sentencias SQL más comunes. Casi todas ellas, salvo contadas excepciones, van a necesitar un buen índice. Hay ocasiones en las que tenemos una tabla con unas pocas decenas de registros a las que no se suele prestar la atención que se debería: sí, ésas también necesitan índice.

Así pues, el asunto se reduce a saber definir qué sentencias SQL van a ser las más usadas, algo que en algunos casos puede no ser trivial.

Por otra parte, tenemos las sentencias SQL raramente usadas pero de mucha carga. Un ejemplo típico es una sentencia SQL usada en la administración de la Web para hacer estadísticas o reportes varios. Si bien es cierto que estas sentencias son raramente utilizadas (¿1 vez por semana?), hay que tener cuidado, pues no sería la primera vez que la Web entera se paraliza 5 minutazos esperando a que la dichosa sentencia deje en paz a nuestro malogrado motor de MySQL.

No estoy diciendo que esas SQL necesiten un índice especial, pero sí que seamos cuidadosos por cuándo las utilicemos. Yo siempre aconsejo la primera hora de la mañana, la hora de comer o, preferiblemente, de madrugada :D

Definir índices cuando la tabla ya está creada
En un mundo ideal, lo mejor es que los índices queden totalmente definidos en el momento se está creando la tabla. Sin embargo, esto no siempre es así. Los requerimientos cambian, por los que las tablas cambian y las sentencias SQL también.

Así que puede darse el caso de que nos toque añadir nuevos índices con un tabla bien repleta. El problema estriba en que la creación de un índice es una operación costosa y pesada. Además, algunos índices sí permiten operaciones SQL de lectura (SELECT), pero bloquean las de escritura (DELETE, UPDATE, INSERT).

Así que el único remedio conocido es... hacerlo cuando menos carga haya :D

Un conocido mío no tuvo mejor idea que añadir un nuevo índice a una tabla un lunes por la mañana... ¡El programa de la empresa cayó todo un día! Imaginaos los costes económicos que implican el no iniciar el proceso de indexación para un viernes por la tarde ;)

El orden de los índices sí altera el resultado. ¡Y mucho!
Hay cosas de MySQL que me cabrean. Una de ellas es que el orden en que definas el índice, debe coincider con el orden en que pongas los filtros WHERE en la sentencia SQL, así como en el ORDER BY

Por ejemplo, si tenemos el índice (a,b,c), no es lo mismo SQL_A que SQL_B:
SQL_A: SELECT * FROM tabla WHERE a=100 AND b=100 ORDER BY c
SQL_B: SELECT * FROM tabla WHERE b=100 AND c=100 ORDER BY a

Más sobre SQL_CALC_FOUND_ROWS vs. COUNT(*)
Hay sentencias SQL que son especialmente óptimas. Por ejemplo, si 'a' es un índice hacer esto:

SELECT COUNT(a) FROM tabla WHERE a=100

Es especialmente eficiente, dado que sólo se accede al índice y en ningún momento a la tabla.

De modo que si en el anterior artículo destacábamos que era mejor el COUNT(*) que el SQL_CALC_FOUND_ROWS, en este caso es especialmente más eficiente.

De hecho, como os podréis imaginar, si 'a' y 'b' son índices, esta sentencia también es muy eficiente:

SELECT b FROM tabla WHERE a=100
comments powered by Disqus
subir