La verdad es que existen errores comunes detrás de los problemas de desempeño de MySQL. 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.

Por suerte, muchos de los problemas de desempeño de MySQL resultan tener soluciones similares, haciendo que solucionar problemas y afinar a MySQL sea una tarea manejable.

Aquí tenemos 10 consejos para obtener un muy buen desempeño de MySQL.

Haga un perfil de su carga de trabajo
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.

La mejor manera 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.

El desarrollo de perfiles de cargas de trabajo agrupa consultas similares, permitiendo que pueda ver las consultas que son lentas, así como las demandas que son rápidas pero que se ejecutan muchas veces.

Entienda los cuatro recursos fundamentales
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.

Cuando se trata de resolver problemas, verifique el desempeño y la utilización de todos los cuatro recursos, con una mirada cuidadosa para poder determinar si es que están desempeñándose pobremente o simplemente se les está exigiendo demasiado trabajo. Este conocimiento puede ayudarle a resolver problemas rápidamente.

No use MySQL como una secuencia
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.

Filtre los resultados empezando por los más económicos
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.

Conozca las dos trampas mortales de la escalabilidad
El crecimiento no es tan vago como podría creer. De hecho, existen definiciones matemáticas precisas de escalabilidad que son expresadas como ecuaciones. Estas ecuaciones resaltan la razón por la cual los sistemas no crecen tan bien como deberían.

Tome la Ley Universal de Escalabilidad, una definición que es útil para expresar y cuantificar las características de escalabilidad de un sistema. Explica los problemas de desarrollo de escalas en términos de dos costos fundamentales: traslado en serie y la diafonía.

Los procesos paralelos que deben detenerse para que algo serializado tome lugar están limitados inherentemente a su escalabilidad. De igual manera, si los procesos paralelos necesitan comunicarse entre ellos todo el tiempo para coordinar su trabajo, éstos se limitan mutuamente.

Evite el traslado en serie y la diafonía y su aplicación crecerá mucho mejor. ¿En qué se traduce todo esto dentro de MySQL? Eso varia, pero algunos ejemplos estarían evadiendo seguros exclusivos en filas. Las secuencias, descritas más arriba, tienden a crecer pobremente debido a esta razón.

No se concentre demasiado en la configuración
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.

Cuídese de las solicitudes de paginación
Las aplicaciones que paginan tienden a hacer que los servidores se arrodillen. Al enseñarle una página de resultados, con un enlace para ir hacia la página siguiente, estas aplicaciones típicamente agrupan y organizan en maneras que hacen imposible el uso de índices, y emplean un LIMIT y offset que ocasiona que el servidor trabaje mucho, generando filas para después descartarlas.

Las optimizaciones con frecuencia pueden ser encontradas en la misma interfaz de usuario. En lugar de mostrar el número exacto de páginas en los resultados y enlaces para cada página individualmente, puede solo mostrar un enlace hacia la página siguiente. También puede evitar que las personas vayan a páginas que se encuentren demasiado lejos de la primera página.

En el lado de la consulta, en lugar de usar LIMIT con offset, puede elegir una fila adicional a las que necesita, y cuando el usuario de un clic en “siguiente página”, puede designar esa fila final como el punto de inicio para el próximo conjunto de resultados. Por ejemplo, si el usuario vio una página con filas desde la 101 hasta la 120, seleccionaría la fila 121; para mostrar la página que sigue, le solicita al servidor llegar a filas mayores o iguales a 121, límite 21.

Guarde las estadísticas con entusiasmo, alerte a regañadientes.
Monitorear y alertar es esencial, pero ¿qué pasa con el típico sistema de monitoreo? Empieza a enviar falsos positivos, y los administradores de sistema establecen reglas de filtrado de correo electrónico para detener el ruido. Pronto, su sistema de monitoreo queda completamente inutilizado.

A mí me gusta pensar sobre el monitoreo de dos formas: capturando medidas y alertando. Es muy importante capturar y guardar todas las medidas que le sea posible porque estará contento de tenerlas cuando esté intentando descubrir qué fue lo que cambió en el sistema.

Algún día, un problema extraño surgirá, y le encantará tener la capacidad de señalar hacia un gráfico y mostrar el cambio en la carga de trabajo del servidor.

En contraste, existe una tendencia de alertar demasiado. Las personas con frecuencia alertan sobre cosas como el ratio hit del buffer o el número de tablas temporales creadas por segundo. El problema es que existe un buen umbral para dicho ratio. El umbral adecuado no solo es distinto de servidor a servidor, sino de hora en hora a medida que su carga de trabajo cambia.

Como resultado, alerte medidamente y solo en condiciones que indiquen un problema definitivo y accionable. Un ratio hit de buffer no es accionable, y tampoco indica un problema real, pero un servidor que no responde a un intento de conexión es un problema real que debe ser resuelto.

Aprenda las tres reglas de indexado
El indexado es probablemente el tema más malentendido en las bases de datos porque existen tantas formas de confundirse sobre cómo funcionan los índices y cómo los usan los servidores. Toma bastante esfuerzo entender qué es lo que está sucediendo realmente.

Cuando son diseñados apropiadamente, los índices tienen tres propósitos importantes en un servidor de base de datos:
1. Los índices le permiten al servidor encontrar grupos de filas adyacentes en vez de filas únicas. Muchas personas piensan que el propósito de un índice es encontrar filas individuales, pero encontrar filas únicas lleva a operaciones aleatorias de disco, lo que es lento. Es mucho mejor encontrar grupos de filas, de las cuales todas o la mayoría son interesantes, que encontrar una fila a la vez.

2. Mediante la lectura de filas en un orden deseado, los índices evitan que el servidor haga la organización. Es costoso organizar. Leer las filas en el orden deseado es mucho más rápido.

3. Los índices le permiten al servidor satisfacer solicitudes únicamente desde el índice, evitando tener que acceder a la tabla. Esto es variadamente conocido como un índice cobertor o consulta exclusiva para índice.
Si es que puede diseñar sus índices y solicitudes para explotar estas tres oportunidades, puede hacer que sus solicitudes sean más rápidas en muchos órdenes de magnitud.

Aproveche la experiencia de sus compañeros
No intente hacerlo solo. Si está pensando en cómo resolver un problema y haciendo lo que le parece lógico y sensato, eso es genial. Esto funcionará 19 de 20 veces. La vez que no funcione, usted se adentrará en un hoyo que será muy costoso y consumirá mucho tiempo precisamente porque la solución que está intentando parece tener mucho sentido.

Construya una red de recursos relacionados con MySQL -y esto va más allá de conjuntos de herramientas y guías de resolución de problemas. Existen personas con bastantes conocimientos que rondan en las listas de correo, foros, páginas web de preguntas y respuestas, y más. Conferencias, shows de comercio y eventos grupales de usuario local proporcionan oportunidades valiosas para obtener conocimientos y construir relaciones con compañeros que pueden ayudarle inmediatamente.

Para aquellos que buscan herramientas para complementar estos consejos, pueden revisar el Configuration Wizard para MySQL, Percona Query Advisor para MySQL, y Percona Monitoring Plugins. (Nota: Tendrá que crear una cuenta Percona para acceder a los dos primeros enlaces. Es gratis). El asistente de configuración puede ayudarle a generar un archivo de línea base my.cnf para un nuevo servidor que es superior a los archivos de prueba que envían con el servidor. El consejero de solicitud analizará su SQL para ayudarle a detectar patrones potencialmente malos como solicitudes de paginación (Nro.7). Percona Monitoring Plugins es un conjunto de conectables para ayudarle a guardar estadísticas con entusiasmo y alertar a regañadientes (Nro.8). Todas estas herramientas están disponibles gratuitamente.

-Baron Schwartz, InfoWorld.com