Tags: registro de consultas lentas
Hacer las consultas más eficiente 1) La localización de las consultas que se ejecutan lentamente
By admin on Mar 17, 2009 | In Gestión etc., Trucos avanzado | Send feedback »
Una de las tareas más importantes para los encargados de administrar un sistema de base de datos (y también para muchos desarrolladores) es que se aseguren de que se ejecute de manera eficaz las consultas. En esta primera parte de varios artículos sobre la optimización de las consultas, voy a mostrar la forma de establecer que las consultas se toma un largo tiempo para llevar a cabo. Esto no siempre es evidente, sobre todo si eres el administrador del sistema y no el usuario.
El sistema de Mysql utiliza algo llamado el registro de consultas lentas (slow query log), lo que puede ser muy útil para optimizar el rendimiento del sistema. Sin embargo, por defecto, MySQL no registra de consultas lentas. Para utilizar este registro, necesitas editar el archivo my.cnf (puede estar en el directorio /etc/mysql/ o, si tienes servidor de lampp, en /opt/lampp/etc/ ). Luego, para poner esta herramiento en marcha, debes asegurarte de que las dos líneas siguientes están escritas:
Code:
log-slow-queries = /var/log/mysql/mysql-slow.log | |
long_query_time = 2 |
En la línea anterior he entrado 2 (por segundos). Puedes cambiar si lo deseas - Tengo entendido que el tiempo por defecto de MySQL es de 20 segundos. Una nota sobre el nombre de ruta para log-slow-queries - Si no se da ningún valor aqui, el nombre por defecto es el nombre de la máquina host con el sufijo -slow.log. Si se da un nombre de archivo, pero no como ruta absoluta, el archivo se escribe en el directorio de datos. Puedes encontrar la ubicación de su directorio de datos por usar mysql y ejecutando el siguiente comando
Code:
SHOW VARIABLES LIKE 'datadir'; |
Otra cosa más. Tendrás que asegurarte de que ya existe un archivo en /var/log/mysql llamado mysql-slow.log (utilizar el comando touch para crear este archivo si estás utilizando una máquina Unix o Linux) y de que los permisos de archivo permiten a los usuarios escribir en ella. Todos están bien, cualquier consulta que funciona después de que el servidor mysql se reinicia, se escribirá en este registro si toman más largo que el período de tiempo especificado.
Si estás interesado en saber más sobre los registros del servidor MySQL, aquí está el enlace para la parte correspondiente del manual
dev.mysql.com doc
Bueno, una vez que hemos establecido que las consultas se tarda mucho tiempo para terminar, tenemos que ver cómo podemos hacer que corra más rápido. En los próximos artículos voy a ver:
* Cambio de la codificación - esto puede implicar un mejor uso de los índices. También puede significar volver a escribir la consulta para utilizar un Join que es generalmente mucho más eficiente de utilizar Mysql en sub-consultas. Tengo que admitir que este ha sido uno de mis puntos débiles. También voy a mostrar las ventajas de usar "Explain plan".
* Malas opciones de indices e ineficiente diseño de bases de datos. A veces la forma de crear índices o tablas de bases de datos de diseño puede tener un impacto negativo en el rendimiento cuestiones
Una cosa que tengo que señalar es que cambian las bases de datos (a través de necesidad) con el tiempo, por lo que, lamentablemente, el rendimiento necesita ser más controldao a intervalos regulares. Sin embargo, se puede ir demasiado lejos en las cosas cambian constantemente para aumentar rendimiento. Debemos ser realistas en relación con estos asuntos. ¿Es que vale la pena el gasto de 4 horas de un dba el momento de hacer una consulta correr 1 segundo más rápido, en caso de que la consulta sólo se ejecute una vez al día o una vez a la semana?
Sentido común (como en todas las cosas) se debe tener en cuenta.
Bueno, espero que el próximo artículo sobre la optimización de consulta salga bastante pronto. Hasta entonces, disfrutar de tu codificación!