Identificar queries lentas en MySQL

ByLuis

Algo muy importante a la hora de desarrollar un proyecto es identificar los puntos que ralentizan la devolución de la página web. Algo que suele provocar esta demora son las sentencias SQL lentas.

En el artículo al que hacemos referencia, explica paso a paso cómo encontrar las queries más lentas. Para ello primero se comprueba si se muestran los logs de sentencias lentas y si no es así, las modificaciones que hay que realizar para que se muestren. Después nos explican el significado de los logs y una utilidad para tratarlos.

Estos consejos solo son válidos para Unix, los usuarios de Windows deberán usar los logs de la aplicación para detectar el punto donde tarda en ejecutarse y luego mediante la sentencia EXPLAIN
estudiar la ejecución de las consultas.

Identifying MySQL slow queries

Vía / dzone

Similar Posts

MySQLTuner: consejos para mejorar el rendimiento de MySQL

ByLuis

MySQLTuner es un script en Perl que realiza un SHOW STATUS y ofrece una serie de consejos fáciles de entender de cómo mejorar el rendimiento en nuestro servidor MySQL.
Este script no te soluciona nada, solo te ofrece consejos que se deberían implementar. Siempre es importante mejorar las queries que se ejecutan para que el rendimiento a nivel de servidor sea menos necesario.
MySQLTuner
Vía / The Pythian Group

Mejora en las consultas anidadas en MySQL6

ByLuis

Buena noticia de rendimiento en la futura versión de MySQL. En este caso se trata de las consultas anidadas dentro de MySQL, pongamos un ejemplo.

Si tenemos esta consulta:

select title, from_date, to_date
from titles
where emp_no in
(select emp_no
from employees
where first_name = 'Mary'
and last_name = 'Sluis'
)

En MySQL5 (usando estos datos) obtendríamos el resultado (1 fila) en 7.88 segundos, mientras que en MySQL6 tardaría 0.13 segundos.

El motivo parece ser que MySQL transforma la subconsulta en un join.

Drizzling MySQL

Replicación en MySQL

ByLuis

Replicar una base de datos MySQL puede sonar a algo muy complicado, resulta más sencillo siguiendo el siguiente artículo que pasamos a comentar. Se trata de una de las base de datos (master) hacer que genere un log y otra (slave) lo lea.

Lo primero es añadir las siguientes líneas al fichero my.conf:

log-bin=<nombre-fichero-log>
binlog-do-db=<nombre-base-datos>
server-id=<numero-servidor>

El nombre de la base de datos si que debe ser el mismo en ambos servidores, los otros dos pueden ser cualesquiera, aunque el nombre del log suele ser el de host seguido de “-bin” y el id del servidor suele ser “1” para el maestro y “2” para el esclavo.

Después debes crear un usuario el cual se usará para replicarse con el esclavo:

GRANT REPLICATION SLAVE ON *.* TO '<usuario>'@'%' IDENTIFIED BY '<contraseña>';

También se puede usar el nombre del servidor esclavo en vez de %. Una vez creado el usuario, actualizamos los datos mediante FLUSH PRIVILEGES y FLUSH TABLES.

Si ejecutamos SHOW MASTER STATUS nos devuelve unos datos que son importantes para la replicación, sobre todo la columna File y la columna Position.

Una vez que el maestro ya está configurado, podemos empezar con la configuración del esclavo, eso sí, antes del inicio de la replicación ambas bases de datos deben tener la misma información. Para configurar el esclavo deberemos modificar su my.conf de la siguiente forma:

server-id=<numero-servidor>

siendo el número distinto al que usamos en el maestro, en nuestro ejemplo el maestro era “1” y el esclavo “2”. Después deberemos ejecutar la siguiente sentencia:

CHANGE MASTER TO MASTER_HOST='<servidor-maestro>', MASTER_USER='<usuario-replicacion>', MASTER_PASSWORD='<contraseña-replicacion>', MASTER_LOG_FILE='<fichero-log>', MASTER_LOG_POS=<posición-log>;

Y ya por último reiniciamos MySQl, paramos el esclavo(STOP SLAVE), cargamos los datos del maestro (LOAD DATA FROM MASTER) y arrancamos el esclavo (START SLAVE).

MySQL replication

Vía / PixelGroovy

| |

Escritura el campos blob en MySQL y PHP

ByLuis

Muy buen artículo que explica cómo almacenar imágenes en campos blob usando MySQL y PHP, el post explica realmente cómo crear galerías de imágenes almacenándolas en campos blob. Yo personalmente no soy muy partidario de esta opción, cuando realmente se debería guardar la ruta de la imagen en el servidor y que el servidor web se encargue de enviar la imágen, ya que si no, lo que hacemos es hacer trabajar bastante a la BD.
De todas formas, el artículo puede sernos útil para saber como almacenar en este tipo de campos, porque aunque el ejemplo no sea del todo correcto, en alguna ocasión si que vamos a necesitar guardar datos en campos blob.
Muy bien explicado, añade conceptos básicos de protección por contraseña, actualización y borrado de imágenes, a parte de un par de consejos sobre los problemas que nos podemos encontrar con la capacidad máxima que se permite subir al servidor usando PHP.
PHP MySQL example: image gallery (blob-storage)
Vía / Good PHP Tutorials

| |

PureEdit: CMS sencillo

ByLuis

PureEdit es un CMS para PHP y MySQL que nos facilitará la labor de desarrollo de la aplicación y la reducirá en tiempo notablemente. Dejándonos el control total del diseño y de la programación.
pureedit.png
Este CMS se basa en la implementación de módulos mediante la definición de tablas en la base de datos, según unos determinados sufijos en los campos de las tablas, se pueden crear relaciones entre módulos y definir el tipo de campo de una forma directa y sencilla.
PureEdit
Vía / Smashing Apps

Revision Engine: engine para MySQL con control de cambios

ByLuis

Revision Engine es un motor para MySQL que permite llevar el control de cambios en los datos de las tablas. Cuando se necesita llevar un registro de las modificaciones realizadas por los inserts y updates, normalmente se realiza mediante programación. Este engine permite que esa tarea sea ajena al programador y que se realice automáticamente por la base de datos.

Existen tres formas de realizar el control de versiones:

  • Uso de dos tablas: una para los datos actuales y otra para el histórico. Las consultas son rápidas pero los updates lentos, ya que hay que quitar de una tabla y ponerla en otra.
  • Usando una tabla en la que se guardan los datos actuales y los históricos, la escritura es más rápida que la anterior, pero la lectura es más lenta porque hay que buscar en un volumen de datos mayor.
  • Usando tablas internas para guardar los cambios realizados en las columnas, no a nivel de la fila completa. Este caso aún no está disponible y lo realizarán en versiones posteriores.

Revision Engine

Vía / The Data Charmer