Mostrar el tiempo transcurrido con MySQL

ByLuis

Algo muy común a la hora de realizar una aplicación web es indicar las fechas según el tiempo transcurrido, en vez de poner 2009-06-03 poner “hace 7 días”.

Para aquellos que necesiten mostrar las fechas de esta forma usando MySQL es posible hacerlo usando una función:

DELIMITER //
CREATE FUNCTION TimeDiffUnits (old DATETIME, new DATETIME) RETURNS CHAR(50) DETERMINISTIC NO SQL
BEGIN
DECLARE diff INTEGER;
SET diff = UNIX_TIMESTAMP(new) - UNIX_TIMESTAMP(old);
CASE
WHEN (diff < 3600) THEN
RETURN CONCAT(FLOOR(diff / 60) , ' Minutes');
WHEN (diff < 86400) THEN
RETURN CONCAT(FLOOR(diff / 3600), ' Hours');
WHEN (diff < 604800) THEN
RETURN CONCAT(FLOOR(diff / 86400), ' Days');
WHEN (diff < 2592000) THEN
RETURN CONCAT(FLOOR(diff / 604800), ' Weeks');
WHEN (diff < 31536000) THEN
RETURN CONCAT(FLOOR(diff / 2592000), ' Months');
ELSE
RETURN CONCAT(FLOOR(diff / 31536000), ' Years');
END CASE;
END //
DELIMITER ;

Importante: no uséis jamás está función ni en el WHERE ni en el ORDER BY ni en el GROUP BY, ya que se ejecutaría para cada registro de las tablas.

User Friendly Age Function for MySQL

Similar Posts

mysqlpdump: backup de MySQL multi-thread

ByLuis

El tema de realizar las copias de seguridad de una base de datos en MySQL suele ser un problema debido a la cantidad de recursos que puede necesitar si las BDs ocupan mucho espacio.
Para solucionar algo este problema existe la aplicación mysqlpdump, la cual realiza en paralelo la copia de seguridad de cada tabla, siendo esto muy beneficioso en los servidores con más de una CPU.
Un ejemplo de eficiencia que comentan es una BD de 300G que tarda en realizar la copia de seguridad en 3 horas y media.
Por defecto, se crean ficheros independientes para cada tabla, incluso se puede sacar la salida por pantalla, algo nada recomendable.
Se requiere Python 2.5 y el módulo MySQL-python.
mysqlpdump
Vía / MySQL-HA

Procedimientos almacenados de lenguajes externos para MySQL6

ByLuis

External Language Stored Procedures for MySQL es un parche para MySQL 6 que nos permite ejecutar procedimientos almacenados creados en otro lenguaje de programación externo a MySQL.

Los procedimientos almacenados se declaran en SQL usando sintaxis estándar de compilación, mientras que los que se implementan en otros lenguajes de programación se implementan como plugins que se instalan en el servidor en tiempo de ejecución.

Actualmente admite los plugins para Java y Perl, además de dar soporte a peticiones XML-RPC como procedimientos almacenados.

Un ejemplo para Perl sería el siguiente:

sub test1() {
my $dsn= "DBI:mysql:test";
my $dbh= DBI->connect($dsn, undef, undef) or
die "Error al conectar";
$dbh->do("INSERT INTO t1 (txt) VALUES ('hello world')");
return 0;
}

Y se usaría de la siguiente manera:

mysql> CREATE TABLE test.t1 (
seq INT NOT NULL AUTO INCREMENT PRIMARY KEY,
txt VARCHAR(128));
mysql> CREATE PROCEDURE test.test1()
LANGUAGE Perl MODIFIES SQL DATA
EXTERNAL NAME 'MyDBIExample::test1';
mysql> LOCK TABLE test.t1 WRITE;
mysql> CALL test.test1();
mysql> UNLOCK TABLES;
mysql> SELECT * FROM test.t1;

External Language Stored Procedures for MySQL

mylvmbackup: copias de seguridad para MySQL

ByLuis

Ya hace tiempo hablé de mylvnbackup como utilidad para realizar copias de seguridad de MySQL cuando se trataba de entorno Linux. Esta vez hablaré con un poco más de profundidad aprovechando que acaban de lanzar la versión 0.10 de esta aplicación.
Esta aplicación bloqueará para lectura todas las tablas y vaciará el caché de disco del servidor, creando un snapshot del directorio de datos de MySQL, desbloqueando las tablas de nuevo. El snapshot toma poto tiempo y cuando se ha realizado el servidor puede continuar funcionando normalmente mientras que el fichero actual de backup continúa.
El snapshot se monta en un directorio temporal y se comprime usando el comando tar, con un formato de fichero así: YYYYMMDD_hhmmss_mysql.tar.gz.
mylvmbackup

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

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

Consejos para optimizar MySQL

ByLuis

Buenos consejos para optimizar MySQL, ordenados por distintas categorías.

Queries

  • Usa EXPLAIN para comprender la ejecución de la query
  • Usa Slow Query Log
  • No uses DISNTINCT cuando usas o puedes usar GROUP BY
  • Crea INSERT o REPLACE en procesos batch y usa LOAD DATA antes que INSERT
  • LIMIT m,n no es tan rápido como parece
  • No uses ORDER BY RAND() si tienes más de dos mil registros
  • Usa SQL_NO_CACHE cuando selecciones datos que se actualizan con frecuencia o son abundantes
  • Evita usar caracteres especiales en los LIKE
  • Evita usar subconsultas correlacionadas en el SELECT y el WHERE
  • No hagas comparaciones calculadas
  • ORDER BY y LIMIT funcionan mejor con
  • No pongas text/blobs en los resultados si no vas a necesitarlos
  • Subqueries en el FROM pueden ser útiles para recuperar BLOBs sin necesidad de ordenarlos. Si haces un join de una tabla consigo misma, puede ser bueno si en la primera obtienes el indice y en segunda obtienes el resto de los datos.
  • ALTER TABLE … ORDER BY puede tomar los datos ordenados cronologicamente y reordenarlos mediante un campo diferente, esto podría hacer que las consultas vayan más rapidas por ese campo, aunque quizás fuera necesario que estuviera en el índice.
  • Es bueno saber cuando dividir una query compleja en la unión de otras más pequeñas
  • Elimina pequeñas cuentas si puedes
  • Haz queries similares para que el cache las use
  • Usa estándares
  • No uses características deprecated
  • Cambia a OR en índices de múltiples campos para que la UNION mejore la velocidad (> mysql 5.0)
  • No uses COUNT (*) en tablas Innodb para cada búsqueda. Para ello deberías usar SQL_CALC_FOUND_ROWS y SELECT FOUND_ROWS()
  • Usa INSERT … ON DUPLICATE KEY update (INSERT IGNORE) para evitar el SELECT

Escalado

  • Usa benchmarking
  • Aisla las cargas de trabajo, no dejes que las tareas administrativas interfieran en el rendimiento (por ejemplo, backups)
  • Testea en vez de hacer debug
  • A la vez que los datos crecen los índices cambian. Haz tu esquema tan modular como tu código.

Rendimiento de red

  • Minimiza el tráfico recuperando solo lo que necesitas.
  • Accede directamente a la paginación con LIMIT no recuperando los anteriores.
  • No uses SELECT *
  • No uses muchas queries rápidas y una algo más compleja puede ser más eficiente.

Mejoras en el sistema operativo

  • Usa particiones en los datos
  • Manten el servidor tan limpio como sea posible
  • Crea un entorno de test

Servidor MySQL

  • innodb_flush_commit=0 puede ayidar en el retraso del slave
  • Optimiza los tipos de datos, se consistente. Usa PROCEDURE ANALYSE() para ayudarte a determinar el tamaño de los datos que necesitas.
  • Si puedes comprime text y blobs
  • Comprime datos estáticos
  • No hagas backup de datos estáticos con frecuencia
  • Activa e incrementa el cache de las queries y el budder si es apropiado
  • Comprueba SHOW STATUS y SHOW VARIABLES
  • Defragmenta tablas, reconstruye índices, haz mantenimiento
  • Aumenta myisam_sort_buffer_size para optimizar inserta largos

Estos son los que me han parecido más interesantes, el resto los podéis encontrar en:

Top 1000 SQL Performance Tips

Gracias David por el aviso