¿Qué opciones de configuración para MySQL proporcionan las mayores mejoras de velocidad?

¿Qué opciones de configuración para MySQL proporcionan las mayores mejoras de velocidad?

Me pregunto acerca de las mejoras reales del archivo de configuración, los tipos de tabla, las configuraciones de hardware, la replicación, etc. Cualquier otra cosa que no sea la estructura de consulta y la estructura de la tabla (estos son fáciles de encontrar en el sitio web y Stack Overflow). ¿Son las configuraciones de caché de consultas las que le dieron la mayor velocidad? ¿Qué hay de las unidades; ¿Es mejor tenerlo en un RAID externo o interno? ¿La replicación le brindó un mejor rendimiento, especialmente con las consultas grandes de lectura?

¿Qué otras configuraciones / cambios ha realizado para mejorar el rendimiento de MySQL?

Nota: Me doy cuenta de que estos dependen mucho del uso (es decir, un sitio web pequeño frente a un almacén de datos), pero como creo que la mayoría de nosotros probablemente trabajamos en una variedad de sitios / sistemas, es bueno conocer una variedad de técnicas que pueden aplicarse a diferentes situaciones Además, creo que algunas técnicas se pueden transferir entre situaciones.

Aquí están mis recomendaciones (su millaje puede variar)

• Use hardware RAID. Esto va en contra de mis recomendaciones para usar RAID de software en otras publicaciones, sin embargo, esta es una situación específica en la que desea la tarjeta RAID de hardware. Específicamente, desea que la NVRAM respaldada por batería en la tarjeta RAID reduzca el tiempo que lleva fsync el archivo de registro al disco.
• Utilice SOLO volúmenes RAID 1 o RAID 10. El costo de las escrituras RAID 5 o 6 es demasiado alto para tolerarlo en una carga de trabajo de lectura / escritura mixta.
• Utilice LUN independientes para los volúmenes de datos, registro y tmp. Todos estos deben estar separados del sistema operativo y los volúmenes de intercambio.
• Utiliza InnoDB .
• Utilice innodb_file_per_table
• Use un sistema operativo de 64 bits
• Establezca su grupo de búferes InnoDB en ~ 80% de su RAM disponible
• Establezca sus archivos de registro a 1/4 del tamaño de su grupo de búferes, tiene entre 2 y 4 archivos de registro. Los archivos de registro más grandes significan tiempos de recuperación y apagado más lentos, pero le permiten restaurar volcados de bases de datos grandes más rápido.
• log_slow_queries, log-queries-not-using-indexes, set-variable = long_query_time = 1, investigue cada consulta en ese registro, refactorice su esquema para evitar escaneos de tablas y tablas tmp siempre que sea posible.

Una vez más, Dave Cheney realmente lo sacó del parque aquí. Realmente no puedo agregar nada a su respuesta a su pregunta. Sin embargo, me gustaría señalar lo que no preguntaste. Como Jeremy Zawodny y Peter Zaitsev me enseñaron hace años, su ROI por el tiempo dedicado a rastrear y optimizar las consultas erróneas superará su ROI por el tiempo dedicado a realizar cambios de configuración 10 veces. Claro, no desea tener una configuración deficiente, una configuración RAID incorrecta o RAM insuficiente. Pero, entre las excelentes consultas, incluso marginales, las consultas incorrectas de MySQL DBA (generalmente de desarrolladores / frameworks, no de DBA) es una condición crónica , donde la mala configuración es soportable .

(Busqué esos adjetivos por un tiempo y todavía no estoy satisfecho con los que elegí).

Me gustaría enfatizar nuevamente que si sus desarrolladores están usando un ORM como los comunes en frameworks como Ruby on Rails y Django, REALMENTE DEBEN monitorear las consultas que lleguen a su base de datos. Cuando los desarrolladores dejan de pensar en SQL y dejan que la base de datos se abstraiga, esto realmente desagradable. Me encantan los dos marcos que acabo de mencionar. (No me rechaces por hablar mal de ellos). Solo hace que Query Sleuthing sea muy importante. (Leer: Seguridad laboral)

Algunas otras cosas (que no se han mencionado en la respuesta de Dave Cheney)

• Intente establecer innodb_flush_method en O_DIRECT para evitar el doble almacenamiento en búfer de datos. Evite esto si su tarjeta RAID no tiene una memoria caché de escritura respaldada por batería o si sus datos están en una SAN.

• Juega también con innodb_thread_concurrency. Creo que el valor predeterminado es 8, pero vale la pena ajustar esto para ver si mejora el rendimiento

• Asegúrese de que el caché de consultas esté activado y verifique las estadísticas para ver cuál es la tasa de aciertos. Si es bueno, intente aumentarlo para ver si mejora la tasa de aciertos.

• Según las aplicaciones que se ejecuten, es posible que pueda cambiar el nivel de aislamiento predeterminado. El valor predeterminado es REPEATABLE_READ pero READ_COMMITTED podría brindarle un mejor rendimiento

• Si sus declaraciones son principalmente ACTUALIZACIONES y DELETES, entonces puede intentar cebar el caché en el esclavo haciendo una consulta SELECT que devuelve el conjunto de resultados que se va a modificar. Echa un vistazo a la herramienta mk-slave-prefetch que hará esto por ti

• Eche un vistazo a otros motores de almacenamiento aparte de MyISAM e InnoDB

No puedo decir nada sobre el hardware, pero puede probar http://blog.mysqltuner.com . Es un script de Perl que analiza la configuración de MySQL.

Puede ver una salida de muestra en http://www.thomas-krenn.com/de/wiki/MySQL_Performance_Tuning#mysqltuner.pl

Lo primero que debe hacer en general es mirar los parámetros de memoria. La configuración predeterminada para MySQL es muy muy conservadora. Cualquiera que sea el motor que use, probablemente necesitará aumentar una cantidad de parámetros de memoria en diez o incluso cien veces.

Lo siguiente que debe hacer es mirar el caché de la tabla. El valor predeterminado es 64, que solo es útil si no tiene más de aproximadamente 60 tablas. Querrás plantear eso un largo camino.

La tercera cosa que debe hacer es mirar el hilo y los parámetros de conexión. El valor predeterminado wait_timeout es enormemente largo para la mayoría de las aplicaciones basadas en la web y puede reducirse a unos 30 segundos. Esto también mejorará el uso de la memoria, ya que MySQL cosechará conexiones antes, dejando mucho menos en estado de "suspensión".