¿Cuál es la mejor herramienta de rendimiento amigable para el usuario para MySQL? Me gustaría ayuda para localizar el cuello de la botella de mi configuración. ¿El problema está en las sentencias de SQL, las variables de configuración o alguna otra cosa?¿La mejor herramienta de ajuste de rendimiento MySQL?
Las malas noticias: hay herramientas GUI para ayudar con esto, pero es un trabajo calificado y amplio. Por lo tanto, no cubren todo, es probable que necesites usar instrucciones de línea de comando/sql, etc. para ayudar. Realmente solo he usado las herramientas de línea de comando. Daré un poco de una descripción de las cosas que sé/he usado:
Primero, necesitas un buen diseño de base de datos. Si el diseño es malo, solo puedes llegar tan lejos. Esto incluye la normalización, así como el uso de tipos apropiados para los campos. Dejaré este punto aquí, ya que creo que está un poco a un lado, y no lo que busca.
Asegúrate de que MySQL Query Cache esté configurado y en funcionamiento y dale un poco más de RAM si puedes, y asegúrate de que tus consultas importantes no estén haciendo nada que impida que mysql las guarde en caché. Por ejemplo, el uso de la función NOW() en las consultas lo hace, por razones obvias, ¡NOW cambia cada segundo! En su lugar, puede poner una marca de tiempo en el sql, y usar la hora al minuto/hora/día más cercano (el período más largo con el que puede salirse con la suya) para permitir que mysql obtenga algún beneficio de almacenamiento en caché.
Para comenzar a optimizar cosas: pegar "EXPLAIN" delante de seleccionar es LA forma de ver cómo se está ejecutando una consulta e idetificar cómo mejorarla. Aprenda a interpretar el resultado: http://dev.mysql.com/doc/refman/5.0/en/using-explain.html A menudo podrá agregar nuevos índices/agregar columnas a los existentes para mejorar las cosas. Pero también encontrará tiempos en que las consultas deben ser reestructuradas.
Comenzar a mejorar el rendimiento con MySQL (asumiendo que usted no sabe ya cuál es la consulta problemática) es verificar el registro lento de consultas - registra en un archivo todas las consultas que toman más de x segundos.
Descripción general, incluida la configuración para si ya no está registrando, está aquí: http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html - También he encontrado que establecer long_query_time en 0 por un día, para que todas las consultas se registren aquí con el tiempo, es una forma útil de tener una idea de dónde va exactamente el rendimiento. ¡Pero yo no iría allí de inmediato! Y no lo dejes, los registros pueden volverse masivos.
Una vez que tenga unos días de registro, he encontrado mysqlsla (analizador de registro lento de mysql) desde aquí: http://hackmysql.com/mysqlsla es una buena herramienta.
Puede hacer mucho más que solo ralentizar el análisis de registro de consultas: lea el manual. Pero para explicar lo que hace para los registros lentos: el registro lento de consultas puede contener una gran cantidad de datos, por lo que puede ser difícil determinar qué consultas son las más costosas en general, por ejemplo: factor de cuántas veces se ejecutan y cuándo dos consultas son en realidad lo mismo con una identificación diferente en una cláusula where.
MySQL sla hace esto todo para usted. Se ejecuta a través del registro y puede agrupar consultas que son iguales/tienen valores diferentes en las cláusulas where. Luego le presenta (de manera predeterminada) las 10 consultas principales en términos de tiempo total de ejecución, que a menudo tiene algunas sorpresas, pero generalmente es el punto de partida más productivo, tome la consulta más cara y use EXPLAIN en ella y vea si puede mejorar eso.
Algunas consultas tardan mucho tiempo y no se pueden mejorar fácilmente. En este caso, ¿puede obtener los datos de otra manera o al menos almacenarlos en caché? Incluso puede encontrar que se requiere cambiar el esquema DB. Del mismo modo, algunas consultas pueden estar en la parte superior de la salida de mysqlsla porque las ejecuta mucho (especialmente cierto si long_query_time está establecido en 0), incluso si se ejecutan bastante rápido. Tal vez es hora de agregar un poco de almacenamiento en caché a su aplicación?
http://www.maatkit.org/ también parece prometedor, nunca lo usó, pero la herramienta mk-query-profiler debería ser útil para analizar con mayor detalle por qué las consultas se ralentizan.
Una cosa completamente separada para mirar también: la página de "estado" en PHPMYADMIN (o puede ejecutar todas las consultas para generar esta información ...) - resalta las cosas que piensa que podrían estar mal en rojo, y puede ayudarlo a ver dónde puede obtener beneficios asignando recursos del sistema. No sé mucho sobre esto, mi enfoque siempre ha sido que si algo es rojo y se ve mal, ir a leer sobre él y decidir si es importante y si debería hacer algo (generalmente significa asignar más recursos a MySQL). cambiando la configuración).
Recientemente he encontrado que ejecutar SHOW PROCESSLIST también puede ser útil en un servidor que está sufriendo. Si bien solo le brinda información en vivo (bueno, una instantánea en vivo), puede ayudarlo a tener una idea de lo que está sucediendo en un momento dado, especialmente si actualiza algunas veces y observa los cambios. Recientemente descubrí un servidor que usaba todas las conexiones de mysql disponibles para ejecutar una consulta idéntica con este método. Claro, habría estado en el registro lento de consultas, pero esta era una manera muy rápida y obvia de ver qué sucedía.
EXPLAIN es tu amigo. Aparte de eso, debe confiar en una mezcla de herramientas ad-hoc, pruebas y herramientas del sistema operativo para ver exactamente qué está pasando.
Se pueden ver muchas cosas con eficacia desde las herramientas del sistema operativo (bueno para determinar si una situación es CPU o IO obligado) o las diversas variables que se pueden ver en MySQL (mostrar variables globales, mostrar el estado del motor innodb etc.)
Creo que es realmente importante tener un ENTORNO DE PRUEBA DE RENDIMIENTO. Obtenga una base de datos de tamaño de producción con carga similar a la producción (usando simulación de carga) ejecutándose en hardware de producción en su laboratorio (costosa pero esencial).
Una vez que haya hecho eso, puede ajustar cualquier parámetro que desee con total seguridad, sabiendo que incluso si se derrite todo el servidor, puede reconstruirlo sin afectar nada.
No haga cosas específicas que las personas sugieran a menos que las haya probado en su entorno de prueba de rendimiento y las haya comprobado como beneficiosas.
Esencialmente, la optimización del rendimiento por lo general se ve en tres áreas, en este orden:
Las dos primeras a menudo se pasan por alto a favor de la última, lo que puede ayudar, pero solo después de que las dos primeras hayan terminado.
No subestime la importancia de reducir la cantidad de trabajo que el servidor necesita hacer: utilizar campos más pequeños, menos filas, menos columnas, etc., siempre es mejor.
Encontré MONyog para ser una GRAN ayuda cuando tenía un servidor de mysql que sufría.
Es un sistema basado en web que analiza su sistema 24/7 y le da sugerencias decentes para mejores valores de variables del sistema, tamaños de caché, etc.
También tiene una característica incorporada en el analizador de consultas lentas tipo mysqlsla.
Lástima que no es gratis. 
MONyog- MySQL monitor y Asesor tiene nueva interfaz de usuario, que me encanta, me gusta su mayoría estas características:
Supervisión de la replicación
etc .... Complete feature list
... Wow divertida de ver esta fue aceptada después de casi un año :) – benlumley
1 para el explicar, ayudar mucho en mi proyecto aquí! –
Según tengo entendido, mysqlsla y maatkit se fusionaron en el kit de herramientas de percona. Sin embargo, el buen visor de registro de consultas lento mysql está basado en la web https://github.com/benkaiser/mysql-slow-query-log-visualizer – Bachor