it-swarm-es.com

¿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 tablas, las configuraciones de hardware, la replicación, etc. Cualquier otra cosa que no sea la estructura de la consulta y la estructura de la tabla (estas son fáciles de encontrar en el sitio web y Stack Overflow). ¿Son cosas como la configuración de la caché de consultas lo que le dio más velocidad? ¿Qué hay de las unidades? ¿Es mejor tenerlo en un RAID externo o interno? ¿La replicación le proporcionó un mejor rendimiento, especialmente con consultas de lectura grandes?

¿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 se pueden aplicar a diferentes situaciones. Además, creo que algunas técnicas se pueden transferir entre situaciones.

29
Darryl Hein

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

  • Utilice RAID de hardware. Esto va en contra de mis recomendaciones de usar software RAID 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 para llevar el archivo de registro fsync 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 mixta de lectura/escritura.
  • 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.
  • Utilice InnoDB .
  • Utilice innodb_file_per_table
  • Utilice un sistema operativo de 64 bits
  • Configure su grupo de búfer InnoDB en ~ 80% de su RAM disponible
  • Establezca sus archivos de registro en 1/4 del tamaño de su grupo de búfer, entre 2 y 4 archivos de registro. Los archivos de registro más grandes significan tiempos de apagado y recuperación más lentos, pero le permiten restaurar grandes volcados de bases de datos 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.
20
Dave Cheney

Una vez más, Dave Cheney realmente lo dejó fuera del parque aquí. Realmente no puedo agregar nada a su respuesta a tu 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 incorrectas superará su ROI por el tiempo dedicado a realizar cambios de configuración 10 veces. Claro, no desea tener una configuración deficiente, la configuración RAID incorrecta o RAM insuficiente. Pero, entre las consultas erróneas excelentes, e incluso marginales, de los DBA de MySQL (generalmente de desarrolladores/frameworks, no del DBA) es una condición crónica, donde una mala configuración es una soportable una .

(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 marcos como Ruby en Rails y Django, REALMENTE DEBE monitorear el consultas que llegan a su base de datos. Cuando los desarrolladores dejan de pensar en SQL y dejan que la base de datos se abstraiga, esto es realmente desagradable. Me encantan los dos marcos que acabo de mencionar. (No me rechacen por hablar mal de ellos). hace que Query Sleuthing sea muy importante. (Leer: Seguridad laboral)

11
Bruno Bronosky

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

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

  • También juega con innodb_thread_concurrency. Creo que el valor predeterminado es 8, pero vale la pena modificarlo para ver si mejora el rendimiento.

  • Asegúrese de que la caché de consultas esté activada 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 en su mayoría ACTUALIZACIONES y ELIMINACIONES, entonces puede intentar cebar la 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 además de MyISAM e InnoDB

4
Nathan

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

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

3
weeheavy

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

Lo siguiente que debe hacer es mirar la caché de la tabla. El valor predeterminado es 64, que solo es útil si no tiene más de 60 tablas. Querrá plantearlo mucho.

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

1
staticsan