El próximo sábado 8 de noviembre a las 19:30 estaré hablando sobre MySQL Fabric en la PyConES 2014 (la versión española de la PyCon), la reunión anual de programadores y entusiastas de Python en España.
Aunque no me auto-denomino como programador, una gran parte de mi tiempo cono consultor de MySQL require implementar procedimientos automáticos (backups, comprobaciones de salud, gestión de AWS, …) y para ello utilizo principalmente una combinación de Python y Bash.

En mi charla, que he titulado “MySQL Fabric, a High Availability solution for Connector/Python” explicaré cómo montar y configurar un conjunto de servidores MySQL y …

El lunes de la próxima semana, 3 de noviembre, impartiré un tutorial de la mayor conferencia europea de MySQL, la Percona Live London 2014. El tema es una continuación natural de la que impartí el año pasado en el mismo lugar, “Optimización de consultas con MySQL 5.6: trucos nuevos y viejos“. Este año me centraré en los últimos cambios en el optimizador que podemos encontrar no sólo en los ya publicados 5.6 y MariaDB 10, pero también alguna de las características de los todavía en desarrollo MySQL 5.7 y MariaDB 10.1. Algunos de los temas de este taller, que he titulado “Optimización de consultas con MySQL …

Como mencioné en mi anterior entrada, donde comparaba las opciones de configuración por defecto de 5.6 y 5.7, he estado haciendo algunos tests para un tipo particular de carga en varias versiones de MySQL. Lo que he estado comprobando es las diferentes maneras de cargar un archivo CSV (el mismo fichero que usé para comprobar las herramientas de compresión) en MySQL. Aquellos administradores de bases de datos y programadores MySQL con experiencia probablemente ya conozcáis la respuesta, así que podéis saltar a los resultados de 5.7 respecto de 5.6. Sin embargo, la primera parte de este post está dedicado a los desarrolladores/aquellos que dan sus primeros pasos con …

Acepto comentarios, puedo estar equivocado :)

• El tipo datetime ocupa 8 bytes y no es timezone-aware. Timestamp ocupa la mitad (4 bytes) y es timezone-aware. Usa timestamp.
• El tipo varchar es más lento que char, pero generalmente ocupa menos espacio. Antes de definir la columna piensa que datos se van a guardar. Si son de tamaño fijo (o muy muy similares) usa char (por ejemplo para un md5).
• Si tu charset es UTF-8, es posible que el string ocupe hasta el tripe de espacio. Usa UTF-8 solamente donde sea necesario.
• Si en un campo varchar o char vas a guardar siempre los mismos strings, usa enum.
• Si no necesitas decimales exactos, usa tipos de coma flotante (float o double). El tipo decimal no lo calcula la CPU (no puede), lo hace MySQL, lo cual es muchisimo más lento.
• Todas las columnas deben ser NOT NULL. Procesar un NULL consume CPU y memoria. Si quieres que los campos se …

Optimizar el rendimiento de una base de datos puede ser una tarea muy compleja, ya que en muchas ocasiones no disponemos de suficiente información o la que tenemos nos hace intentar optimizar consultas o procesos que no merecerá la pena ser optimizados ya que el beneficio puede ser ínfimo.

MySQL pone a nuestra disposición una serie de parámetros y utilidades que pueden ahorrarnos mucho trabajo y facilitarnos la vida a la hora de intentar arreglar aquellas consultas de las que realmente podamos sacar una mejora sensible en el rendimiento.

El primer paso será activar el log dedicado al trazado de consultas lentas. Podémos comprobar fácilmente si lo tenemos ya activado utilizando este comando:

mysqladmin var |grep log_slow_queries
log_slow_queries | OFF

Si el resultado fuera ON, ya tenemos el parámetro activado, pero, al venir en estado OFF por defecto, lo más habitual será que no esté …

Optimizar el rendimiento de una base de datos puede ser una tarea muy compleja, ya que en muchas ocasiones no disponemos de suficiente información o la que tenemos nos hace intentar optimizar consultas o procesos que no merecerá la pena ser optimizados ya que el beneficio puede ser ínfimo.

MySQL pone a nuestra disposición una serie de parámetros y utilidades que pueden ahorrarnos mucho trabajo y facilitarnos la vida a la hora de intentar arreglar aquellas consultas de las que realmente podamos sacar una mejora sensible en el rendimiento.

El primer paso será activar el log dedicado al trazado de consultas lentas. Podémos comprobar fácilmente si lo tenemos ya activado utilizando este comando:

mysqladmin var |grep log_slow_queries
log_slow_queries | OFF

Si el resultado fuera ON, ya tenemos el parámetro activado, pero, al venir en estado OFF por defecto, lo más habitual será que no esté …