MySQL es la base de datos de código abierto más popular del mundo. Con su rendimiento, confiabilidad y facilidad de uso comprobados, MySQL se ha convertido en la principal opción de base de datos para aplicaciones basadas en la Web.

Para asegurar que su MySQL trabaje conjuntamente a su máxima velocidad, desempeñándose de manera estable y consistente, es importante eliminar estos errores, que con frecuencia están escondidos en alguna sutileza dentro de su carga de trabajo o en alguna trampa de configuración.

Para asegurar que su MySQL trabaje conjuntamente a su máxima velocidad, desempeñándose de manera estable y consistente, así que para lograrlo tenemos algunos consejos que te ayudarán en el trabajo diario.

La mejor manera de entender cómo su servidor emplea su tiempo es haciendo un perfil de la carga de trabajo de éste. Haciendo esto, puede sacar a la luz las consultas más onerosas para un afinamiento mayor. Aquí, el tiempo es la medida más importante porque cuando emite una consulta al servidor, más que cualquier otra cosa, a usted le importa qué tan rápido se completa ésta.

Una de las formas más efectivas de hacer un perfil de su carga de trabajo es usando la herramienta de análisis de consultas, MySQL Enterprise Monitor o la pt-query-digest de Percona Toolkit. Estas herramientas capturan las consultas que el servidor ejecuta y devuelve una mesa de tareas organizadas de acuerdo con el orden decreciente del tiempo de respuesta, haciendo que salgan a la superficie las tareas más onerosas y que demandan más tiempo para que pueda ver dónde debe dirigir sus esfuerzos.

Para operar, un servidor de base de datos necesita cuatro recursos fundamentales: CPU, memoria, disco y red. Si cualquiera de éstos es débil, errático o está sobrecargado, es muy probable que la base de datos tenga un desempeño bajo.

Entender los recursos fundamentales es importante en dos áreas particulares: elegir el hardware y solucionar problemas.

Cuando elija un hardware para MySQL, asegúrese de rodearlo con componentes de buen desempeño. Hacer razonablemente bien un balance entre ellos es igual de importante. Con frecuencia, las organizaciones seleccionarán servidores con CPUs y discos rápidos pero que tienen muy poca memoria. En algunos casos, añadir la memoria es una manera barata de aumentar el desempeño por órdenes de magnitud, especialmente en cargas de trabajo que se dirigen al disco. Esto podría parecer contrario a lo esperado, pero en muchos casos los discos son utilizados en exceso porque no existe memoria suficiente para sostener el conjunto de datos del servidor.

Otro buen ejemplo de este balance se aplica a las CPU. En la mayoría de casos, MySQL se desempeñará bien con CPUs rápidas porque cada consulta opera en un subproceso único y no puede ser paralelizado en todas las CPU.

Las secuencias y los patrones de acceso similares a una secuencia pueden infiltrarse en su aplicación sin que lo sepa. Por ejemplo, si instala el estado de un ítem para que un proceso de trabajador particular pueda reclamarlo antes de actuar en éste, creará una secuencia sin saberlo. Marcar correos electrónicos como no enviados, enviarlos y después marcarlos como enviados es un ejemplo común.

Las secuencias causan problemas por dos razones principales: Éstas hacen que su carga de trabajo se serialice, evitando que las tareas se realicen en paralelo, y con frecuencia resultan en una tabla que contiene trabajo en proceso, así como información histórica de trabajos que fueron procesados hace mucho tiempo. Ambos añaden tiempo de espera a la aplicación y se cargan a MySQL.

Una gran manera de optimizar MySQL es empezar por realizar el trabajo barato e impreciso, y después realizar un trabajo duro y preciso en el conjunto de datos resultante.

Por ejemplo, suponga que está buscando algo dentro de un radio determinado de un punto geográfico. La primera herramienta de muchos programadores es la fórmula de aproximación esférica de Haversine, que sirve para computar la distancia entre dos puntos de la superficie de una esfera. El problema con esta técnica es que la fórmula requiere muchas operaciones de trigonometría, que son muy intensivas para la CPU. Los cálculos de la fórmula de Haversine hacen que la utilización de la CPU crezca significativamente.

Antes de aplicar la fórmula de Haversine, reduzca sus registros a un subconjunto pequeño del total, y recorte el conjunto resultante para obtener un círculo preciso. Un cuadrado que contiene al círculo (precisamente o imprecisamente) es una manera fácil de hacer esto. De esa manera, el mundo fuera del cuadrado nunca se ve golpeado por todas esas funciones costosas de trigonometría.

Los DBA tienden a emplear mucho tiempo haciendo ajustes en las configuraciones. El resultado usualmente no es una mejora grande y a veces incluso puede ocasionar bastante daño. He visto muchos servidores “optimizados” que han colapsado constantemente, que se han quedado sin memoria, y que se han desempeñado pobremente cuando la carga de trabajo se volvía un poco más intensa.

Los defaults que se envían con MySQL no son de utilidad para nadie y son bastante obsoletos, pero no tiene que configurarlo todo. Es mejor conseguir los derechos fundamentales y cambiar otras configuraciones solo si es necesario. En la mayoría de los casos, puede obtener el 95% del pico de desempeño configurando solo 10 opciones correctas. Las pocas situaciones donde esto no aplica van a ser casos extremos que son únicos para sus propias circunstancias.

En la mayoría de casos, las herramientas de “afinamiento” de servidor no son recomendadas porque tienden a proporcionar guías que no tienen sentido para casos específicos. Algunas incluso tienen dentro de ellas consejos codificados incorrectos -como ratios cache hit y fórmulas de consumo de memoria. Estas nunca estuvieron bien, y se han convertido incluso en algo más impreciso con el paso del tiempo.