El uso máximo de memoria de MySQL depende en gran medida del hardware, su configuración y la propia base de datos.
Hardware
El hardware es la parte obvia. Cuanta más RAM, mejores y más rápidos los discos ftw . Sin embargo, no crea en esos boletines informativos mensuales o semanales. MySQL no escala de forma lineal, ni siquiera en el hardware de Oracle. Es un poco más complicado que eso.
La conclusión es:no existe una regla general sobre lo que se recomienda para su Configuración de MySQL. Todo depende del uso actual o de las proyecciones.
Configuración y base de datos
MySQL ofrece innumerables variables y conmutadores para optimizar su comportamiento. Si tiene problemas, realmente necesita sentarse y leer el (f'ing) manual.
En cuanto a la base de datos, algunas limitaciones importantes:
- motor de tablas (
InnoDB,MyISAM, ...) - tamaño
- índices
- uso
La mayoría de los consejos de MySQL sobre stackoverflow le informarán sobre 5-8 configuraciones importantes. En primer lugar, no todos importan, p. asignar muchos recursos a InnoDB y no usar InnoDB no tiene mucho sentido porque esos recursos se desperdician.
O, mucha gente sugiere aumentar la max_connection variable:bueno, no saben que también implica que MySQL asignará más recursos para atender esas max_connections - si alguna vez es necesario. La solución más obvia podría ser cerrar la conexión de la base de datos en su DBAL o reducir el wait_timeout para liberar esos hilos.
Si me entiendes, realmente hay mucho, mucho para leer y aprender.
Motores
Los motores de tablas son una decisión bastante importante, muchas personas se olvidan de ellos desde el principio y luego, de repente, se encuentran luchando con un MyISAM de 30 GB. tabla que bloquea y bloquea toda su aplicación.
No quiero decir que MyISAM apesta , pero InnoDB se puede ajustar para responder casi o casi tan rápido como MyISAM y ofrece algo como el bloqueo de filas en UPDATE mientras que MyISAM bloquea toda la tabla cuando se escribe en ella.
Si tiene la libertad de ejecutar MySQL en su propia infraestructura, también puede consultar el servidor percona
porque además de incluir muchas contribuciones de compañías como Facebook y Google (lo saben rápido), también incluye el reemplazo directo de Percona para InnoDB , llamado XtraDB .
Vea mi esencia para la configuración del servidor percona (y del cliente) (en Ubuntu):http://gist.github .com/637669
Tamaño
El tamaño de la base de datos es muy, muy importante; créalo o no, la mayoría de las personas en Intarwebs nunca han manejado una configuración de MySQL grande y de escritura intensa, pero realmente existen. Algunas personas bromearán y dirán algo como "¡Usa PostgreSQL! 111", pero ignorémoslos por ahora.
La conclusión es:a juzgar por el tamaño, se debe tomar una decisión sobre el hardware. Realmente no puedes hacer que una base de datos de 80 GB funcione rápido con 1 GB de RAM.
Índices
No es:cuanto más, mejor. Solo se deben configurar los índices necesarios y se debe verificar el uso con EXPLAIN . Agregue a eso que EXPLAIN de MySQL es realmente limitado, pero es un comienzo.
Configuraciones sugeridas
Acerca de estos my-large.cnf y my-medium.cnf archivos, ni siquiera sé para quién fueron escritos. Enrolla el tuyo propio.
Imprimación de afinación
Un gran comienzo es el cartilla de ajuste
. Es un script bash (pista:necesitarás Linux) que toma la salida de SHOW VARIABLES y SHOW STATUS y lo envuelve en una recomendación con suerte útil. Si su servidor ha estado funcionando durante algún tiempo, la recomendación será mejor ya que habrá datos en los que basarla.
Sin embargo, la base de afinación no es una salsa mágica. Aún debe leer sobre todas las variables que sugiere cambiar.
Lectura
Me gusta mucho recomendar el mysqlperformanceblog . Es un gran recurso para todo tipo de consejos relacionados con MySQL. Y no se trata solo de MySQL, también saben mucho sobre el hardware adecuado o recomiendan configuraciones para AWS, etc. Estos muchachos tienen años y años de experiencia.
Otro gran recurso es planet-mysql , por supuesto.
