Mysql

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 datosson el 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, inicialmentefuncionaba bien, 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.Al
desarrollar 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 mayorconcurrencia puede poner 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 tocadoalgo?” o incluso “Hoy la 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 resolver el 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 sistemaoperativo... hasta llegar a la base de 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 modificar la 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 eltiempo (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...