Mysqloptimizacion

Optimización de MySQL II – Las Consultas

Optimización de MySQL
Tras analizar en nuestro primer artículo la optimización del modelo de datos, continuamos viendo cómo obtener el mejor rendimiento de nuestro servidor de Base de Datos MySQL. Nos centramos ahora en la optimización de las consultas SQL.

Optimización de MySQL II – Las Consultas
Introducción
Las consultas a la base de datos sonel típico punto de degradación de una aplicación tras varios meses o años de funcionamiento. Salvo que nuestra aplicación realice operaciones masivas de inserción de registros, debemos preocuparnos sólo de las operaciones de SELECT. Es en este tipo de operaciones donde notaremos como, poco a poco, se va degradando nuestra aplicación. La degradación de una consulta que, inicialmente funcionababien, se produce por dos motivos. En primer lugar, porque crece el número de registros de nuestra base de datos. Lo habitual es que, al poner la aplicación en marcha tengamos pocos registros (clientes, pedidos, expedientes...) y que, según transcurre el tiempo, las tablas tengan cada vez más registros. El segundo motivo de degradación es el incremento del número de usuarios, la concurrencia. Aldesarrollar la aplicación posiblemente las consultas se probaron con un único usuario. A lo sumo con alguna simulación de carga (pero esto no es muy habitual). Incluso tras la puesta en marcha suele haber un periodo de aceptación en el que los usuarios van incorporándose poco a poco a la aplicación, usándola cada día un poco más. Esta combinación de mayor cantidad de datos y mayor concurrencia puedeponer en evidencia un diseño poco profesional de las consultas. Naturalmente nuestras consultas estarán embebidas en un aplicación, no es habitual que los usuarios lancen consultas SQL directamente a la base de datos. Así que, los primeros síntomas de que algo empieza a fallar serán “esporádicos”. Tendremos comentarios como “La búsqueda de clientes va más lenta, ¿habéis tocado algo?” o incluso “Hoyla red va muy mal, alguien estará bajando películas”. Comentarios que no constituyen quejas formales y que, fácilmente pueden ser achacados a otras causas. Pero la degradación de las consultas, aunque lenta, es progresiva. Y poco a poco (o quizás no tan poco a poco) nuestra aplicación se irá degradando hasta la sublevación de los usuarios. Antes de que ocurra deberemos “remangarnos” para resolverel problema.

Detección
Lo primero es detectar el problema, saber qué está pasando. Puede que en un principio nada nos haga sospechar de la base de datos. Simplemente, algunas operaciones de usuario (búsquedas, listados, etc.) serán lentas “esporádicamente”. Iniciaremos nuestra operación de búsqueda descartando factores... la red, el servidor web, el sistema operativo... hasta llegar a la basede datos. Pero... ¿cómo podemos determinar si la base de datos es
Miguel Jaque Barbero (mjaque@ilkebenson.com) Página 1 de 1

Optimización de MySQL II – Las Consultas el cuello de botella? Afortunadamente MySQL tiene un log específico para detectar este tipo de situaciones, el “Slow Query Log”. Nos bastará con activar este log durante unos días y analizarlo. Para ello, tendremos que modificarla sección [mysqld] del fichero de configuración (my.cnf): log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 2 log-queries-not-using-indexes Con la primera directiva estamos indicando en qué fichero se guardará el log. Conviene asegurarse de que existe un proceso de rotación para ese log (logrotate). Con la segunda directiva establecemos el tiempo (en segundos). En este caso,cualquier consulta que tarde más de 2 segundos en ejecutarse se considerará lenta y será registrada en el log. Y en la tercera directiva hará que también se registren en el log las consultas que no utilicen ningún índice para su resolución. Revisando este log, tras varias horas o días de recogida de información, podremos identificar las consultas lentas de nuestra aplicación. Hay que tener en cuenta...