O uso máximo de memória do MySQL depende muito do hardware, suas configurações e o próprio banco de dados.
Hardware
O hardware é a parte óbvia. Quanto mais RAM, melhores e mais rápidos os discos ftw . Mas não acredite nessas cartas de notícias mensais ou semanais. MySQL não escala linear - nem mesmo em hardware Oracle. É um pouco mais complicado do que isso.
A conclusão é:não há uma regra geral para o que é recomendado para seu 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 switches para otimizar seu comportamento. Se você tiver problemas, você realmente precisa sentar e ler o manual (f'ing).
Quanto ao banco de dados -- algumas restrições importantes:
- mecanismo de tabela (
InnoDB,MyISAM, ...) - tamanho
- índices
- uso
A maioria das dicas do MySQL sobre stackoverflow lhe dirá sobre 5-8 configurações importantes. Em primeiro lugar, nem todos 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 o
max_connection variável -- bem, mal eles sabem que isso também implica que o MySQL alocará mais recursos para atender essas 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 tópicos. Se você me entende - há realmente muito, muito para ler e aprender.
Motores
Os mecanismos de tabela são uma decisão muito importante, muitas pessoas se esquecem deles no início e, de repente, se veem lutando com um
MyISAM de 30 GB de tamanho tabela que bloqueia e bloqueia toda a sua aplicação. Eu 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 bloqueio de linha em UPDATE enquanto MyISAM bloqueia a tabela inteira quando ela é gravada. Se você tem liberdade para rodar o MySQL em sua própria infraestrutura, você também pode querer conferir o servidor percona porque entre incluir muitas contribuições de empresas como Facebook e Google (eles sabem rápido), também inclui o próprio substituto do Percona para
InnoDB , chamado XtraDB . Veja minha essência para configuração do 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 na Intarwebs nunca lidou com uma configuração MySQL grande e intensa, mas elas realmente existem. Algumas pessoas vão trollar e dizer algo como "Use PostgreSQL!!!111", mas vamos ignorá-las por enquanto.
A linha inferior é:a julgar pelo tamanho, a decisão sobre o hardware deve ser tomada. Você não pode realmente fazer um banco de dados de 80 GB rodar rápido 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 EXPLAIN do MySQL é realmente limitado, mas é um começo. Configurações sugeridas
Sobre estes
my-large.cnf e my-medium.cnf arquivos - eu nem sei para quem foram escritos. Role o seu próprio. Primário de ajuste
Um ótimo começo é o primer de ajuste . É um script bash (dica:você precisará do linux) que recebe a saída de
SHOW VARIABLES e SHOW STATUS e o envolve em uma recomendação útil. Se o seu servidor já funcionou há algum tempo, a recomendação será melhor, pois haverá dados para baseá-los. O primer de ajuste não é um molho mágico. Você ainda deve ler todas as variáveis que ele sugere mudar.
Leitura
Eu realmente gosto de recomendar o mysqlperformanceblog . É um ótimo recurso para todos os tipos de dicas relacionadas ao MySQL. E não é só 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 ótimo recurso é o planet-mysql , é claro.
