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

Similar Posts

Autosugerencias usando MySQL índices fulltext

ByLuis

Interesante seríe de tres artículos que nos muestra como crear un autosuggest tipo Google usando los índices full-text de MySQL. El método no es nada sencillo (php, mysql y listo), por lo que no será fácil probarlo, pero tampoco complicado o imposible (se necesita ser un usuario algo más avanzado).
Se trata de coger el fichero del índice full-text y usando un programa C, que es necesario compilar junto a MySQL, accederá a los términos que cumplan el texto base del auto-suggest y lo devolverá.
Como ya he comentado se trata de una aplicación externa, por lo que su integración con nuestra aplicación web deberá ejecutarla como proceso externo.
Implementing an AutoSuggest feature using MySQL fulltext indices

|

HeidiSQL: cliente para MySQL

ByLuis

heidisql.pngHeidiSQL es un cliente open source para MySQL que permite manejar y visualizar las bases de datos y las tablas de MySQL. Algo parecido a lo que ya hacen MySQL Query Browser o SQLYog.

heidisql2.png

Entre las características que nos ofrece encontramos lo siguiente:

  • Generar informes SQL
  • Sincronizar tablas entre dos bases de datos
  • Manjar privilegios de usuarios
  • Importar ficheros de texto
  • Exportar los datos de una tabla en formato CSV, HTML o XML
  • Visualizar y editar los datos de una tabla
  • Insercion de ficheros ascii o binarios
  • Editor SQL con sintaxis resaltada y autocompletado
  • Monitorizar y eliminar procesos cliente

Además existe una versión portable

HeidiSQL

| |

Sphinx: buscador de texto open source

ByLuis

sphinx.pngSphinx (SQL Phrase Index) es un motor que permite buscar texto. Normalmente es un motor de búsqueda independiente, que provee de forma rápida y eficiente resultados relevantes a otras aplicaciones. Está diseñado para ser integrado con MySQL y lenguajes de programación (actualmente PHP). Los datos se pueden recuperar mediante conexión directa a MySQL o mediante XMLs.

Dispone de cuatro utilidades: indexer para crear índeces de texto, search para buscar desde la línea de comandos, searchd es un demonio que busca en los textos desde aplicaciones externas y sphinxapi un API para lenguajes de programación (PHP).

Entre las características que ofrece nos encontramos con lo siguiente:

  • Alta velocidad de indexación (+10Mb/s)
  • Alta velocidad de búsqueda (0.1 s. en 2-4 Gb de texto)
  • Alta escalabilidad
  • Soporte para búsquedas distribuidas
  • Soporte para MySQL nativo (admite tablas MyISAM y InnoDB)
  • Búsqueda de frases
  • Stemming de inglés y ruso
  • Y mucho más

Sphinx

Vía / MySQL Performance Blog

|

Laboratorio: triggers y procedimientos almacenados en MySQL

ByLuis

Unas opciones no muy usadas cuando se trabaja con MySQL son los triggers y los procedimientos almacenados (stored procedures), supongo que a que es algo nuevo en MySQL y la gente no está acostumbrada a estas dos funcionalidades.

Vamos a mostrar un ejemplo de uso de triggers y procedimientos almacenados paso a paso. Quizás el ejemplo no sea el más correcto, o simplemente sea poco útil, pero lo importante es el uso en sí, no el ejemplo.

Nuestro sistema tendrá dos tablas, una con ventas y la otra con comisiones. En la primera se almacenarán cada venta que se realiza en un comercio, y en la segunda las comisiones que le corresponden a cada vendedor en el momento.

CREATE TABLE `ventas` (
`vendedor` int(11),
`producto` int(11),
`importe` float
)
CREATE TABLE `comisiones` (
`vendedor` int(11),
`comision` float
)

Las comisiones se calcula de una forma especial, le corresponde un porcentaje de las ventas según el tipo de producto, y es importante para los vendedores el que se sepa en cada momento qué comisiones lleva ganadas (esto es una justificación para no usar un cron o algo parecido).

Para calcular qué comisión le corresponde a un vendedor, calcularemos los porcentajes para cada tipo de producto vendido y luego lo añadiremos/actualizaremos en la tabla de comisiones. Todo se realizará en un procedimiento almacenado.

DELIMITER $$
DROP PROCEDURE IF EXISTS `test`.`sp_comisiones`$$
CREATE PROCEDURE `test`.`sp_comisiones` (IN mivendedor INT)
BEGIN
DECLARE micomision INT DEFAULT 0;
DECLARE suma INT;
DECLARE existe BOOL;
select IFNULL(sum(importe),0) into suma from ventas where producto = 1 and vendedor = mivendedor;
SET micomision = micomision + (suma * 0.15);
select IFNULL(sum(importe),0) into suma from ventas where producto = 2 and vendedor = mivendedor;
SET micomision = micomision + (suma * 0.1);
select IFNULL(sum(importe),0) into suma from ventas where producto = 3 and vendedor = mivendedor;
SET micomision = micomision + (suma * 0.2);
select count(1)>0 into existe from comisiones where vendedor = mivendedor;
if existe then
UPDATE comisiones set comision = comision+micomision where vendedor = mivendedor;
else
insert into comisiones (vendedor, comision) values (mivendedor, micomision);
end if;
END$$
DELIMITER ;

Ahora, para actualizar los datos de las comisiones usaremos un trigguer, así cuando se haga una venta (insert en la tabla ventas), se llamará al procedimiento almacenado (sp_comisiones), que recalculará la comisión para ese vendedor.

DELIMITER $$
DROP TRIGGER `test`.`tr_ventas_insert`$$
CREATE TRIGGER `test`.`tr_ventas_insert` AFTER INSERT on `test`.`ventas`
FOR EACH ROW BEGIN
call sp_comisiones(new.vendedor);
END$$
DELIMITER ;

Pros y contras de MySQL

ByLuis

MySQL es una de las bases de datos más populares que hay dentro del desarrollo web. Hay gente que la defiende, y otros que no la tienen entre sus BD favoritas. Para aquellos que tengan que decidirse en la elección de MySQL como BD de su sistema, esta lista de pros y contras le puede ser de mucha utilidad.

Pros

  • Es muy popular: el hecho de que mucha gente la use y que esté tan presente en gran parte de los desarrollos web, hace que los proveedores de software intenten que sus aplicaciones sean compatibles con esta BD, pudiendo así encontrar muchas aplicaciones para MySQL.
  • Es simple: es fácil de aprender comparada con otras BDs, no es necesario emplear mucho tiempo o dinero en formar a los trabajadores o en contratar a gente cualificada. El que sea sencilla conlleva que también sea rápida, aunque hay algunos desarrolladores que echan en falta algunas funcionalidades (a mi parecer, cada vez menos).
  • Es barata: aunque pertenece a MySQL AB, MySQL es open source, que sea barata implica que al inicio del proyecto el gasto vaya a otras partes que puedan necesitarlo, en vez de gastar dinero en licencias.
  • Tiene soporte: uno de los inconvenientes que suelen presentar los clientes hacia el open source es que no dispone de soporte. MySQL ofrece licencia con servicios de soporte y mantenimiento, además también es posible obtener atención técnica 24/7.
  • Es flexible y escalable: dispone de muchos tipos de almacenamiento, pudiendo seleccionar el que más nos convenga, y os procedimientos almacenados nos permiten escalabilidad.
  • Librerías nativas para lenguajes: ofrece librerías para lenguajes como PHP y Ruby.

Contras

Yo no estoy personalmente de acuerdo con todas ellas, pero quien escribe el artículo tiene sus razones para indicarlas y hay que tenerlas en cuenta.

  • Licencia GPL: en algunos entornos, la licencia BSD es más adecuada.
  • Falta de integración con entornos existentes: existen muchas circustancias en los que los DBA no tienen un entorno con el que tratar con MySQL.
  • Falta de madurez: en comparación con otras BDs como Oracle (que cumple 30 años), le falta madurez, lo que indica posicionamiento y estabilidad.
  • Falta de características: hay características importantes, que aunque a veces no son muy utilizadas, pueden acabar con un proyecto debido a la necesidad de uso.
  • Certificación: a muchas empresas les gusta la certificación, aunque ofrecer certificación, esta está muy lejos de parecerse a la de Oracle o MS-SQL Server.

Five Compelling Reasons to Use MySQL

Eight Sound Reasons Not to Use MySQL

Vía / dzone

mysqlslavesync: clona slaves en MySQL

ByLuis

mysqlslavesync es un script que permite clonar servidores slaves de MySQL (o maestros) para ponerlo en un nuevo servidor slave con mínima interacción.
Se conecta al nodo del origen y realiza un mysqldump o mysqlhotcopy para transferir los datos, recuperar los datos y poner a punto todos los parámetros para la replicación. Empezando entonces la replicación del nuevo slave con el master.
Se trata de una versión inicial, pero nos puede ayudar mucho a la hora de crear un nuevo slave, ya que en poco tiempo tendremos todo funcionando.
mysqlslavesync