O uso máximo de memória do MySQL depende muito do hardware, de suas configurações e do próprio banco de dados.
Hardware
O hardware é a parte óbvia. Quanto mais RAM, melhores e mais rápidos discos ftw . Porém, não acredite nessas cartas de notícias mensais ou semanais. O MySQL não escala linear - nem mesmo em hardware Oracle. É um pouco mais complicado do que isso.
O ponto principal é: não existe uma regra geral para o que é recomendado para sua configuração do MySQL. Tudo depende do uso atual ou das projeções.
Configurações e banco de dados
O MySQL oferece inúmeras variáveis e opções para otimizar seu comportamento. Se você tiver problemas, realmente precisa se sentar e ler o manual (f'ing).
Quanto ao banco de dados - algumas restrições importantes:
- motor de mesa (
InnoDB
, MyISAM
...)
- Tamanho
- índices
- uso
A maioria das dicas do MySQL sobre stackoverflow informará sobre 5-8 as chamadas configurações importantes. Em primeiro lugar, nem todos eles importam - por exemplo, alocar muitos recursos para o InnoDB e não usar o InnoDB não faz muito sentido porque esses recursos são desperdiçados.
Ou - muitas pessoas sugerem aumentar a max_connection
variável - bem, eles mal sabem que isso também implica que o MySQL alocará mais recursos para atendê-los max_connections
- se necessário. A solução mais óbvia pode ser fechar a conexão do banco de dados em seu DBAL ou diminuir o wait_timeout
para liberar esses threads.
Se você me entende - há muito, muito para ler e aprender.
Motores
Os mecanismos de mesa são uma decisão muito importante, muitas pessoas se esquecem deles logo no início e de repente se vêem lutando com uma MyISAM
mesa de 30 GB que trava e bloqueia todo o seu aplicativo.
Não quero dizer que MyISAM é uma merda , mas InnoDB
pode ser ajustado para responder quase ou quase tão rápido quanto MyISAM
e oferece algo como travamento de linha, UPDATE
enquantoMyISAM
trava a tabela inteira quando é escrito.
Se você tem liberdade para executar o MySQL em sua própria infraestrutura, também pode verificar o servidor percona, porque inclui muitas contribuições de empresas como Facebook e Google (eles sabem rápido), também inclui o próprio em substituição de InnoDB
, chamado XtraDB
.
Veja minha essência para configuração de percona-server (e -client) (no Ubuntu): http://gist.github.com/637669
Tamanho
O tamanho do banco de dados é muito, muito importante - acredite ou não, a maioria das pessoas no Intarwebs nunca lidou com uma configuração grande e intensa do MySQL, mas ela realmente existe. Algumas pessoas vão trollar e dizer algo como, "Use PostgreSQL !!! 111", mas vamos ignorá-los por enquanto.
O resultado final é: a julgar pelo tamanho, a decisão sobre o hardware deve ser feita. Você realmente não pode fazer um banco de dados de 80 GB rodar rapidamente em 1 GB de RAM.
Índices
Não é: quanto mais, melhor. Apenas os índices necessários devem ser definidos e o uso deve ser verificado com EXPLAIN
. Adicione a isso que o MySQL EXPLAIN
é realmente limitado, mas é um começo.
Configurações sugeridas
Sobre esses my-large.cnf
e os my-medium.cnf
arquivos - nem sei para quem foram escritos. Faça o seu próprio.
Cartilha de ajuste
Um ótimo começo é a cartilha de ajuste . É um script bash (dica: você vai precisar do linux) que pega a saída de SHOW VARIABLES
eSHOW STATUS
e envolve em uma recomendação útil. Se o seu servidor já rodou há algum tempo, a recomendação será melhor, pois haverá dados para se basear.
O tuning primer não é um molho mágico. Você ainda deve ler sobre todas as variáveis que ele sugere que mudem.
Lendo
Eu realmente gosto de recomendar o mysqlperformanceblog . É um ótimo recurso para todos os tipos de dicas relacionadas ao MySQL. E não é apenas o MySQL, eles também sabem muito sobre o hardware certo ou recomendam configurações para AWS, etc. Esses caras têm anos e anos de experiência.
Outro grande recurso é o planet-mysql , é claro.