it-swarm-pt.tech

Quais opções de configuração para o MySQL fornecem as maiores melhorias de velocidade?

Quais opções de configuração para o MySQL fornecem as maiores melhorias de velocidade?

Estou me perguntando sobre as melhorias reais do arquivo de configuração, tipos de tabela, configurações de hardware, replicação, etc. Qualquer coisa além da estrutura de consulta e estrutura de tabela (estas são fáceis de encontrar no site e Stack Overflow). Coisas como configurações de cache de consulta são o que oferece mais velocidade? Que tal drives; é melhor tê-lo em um RAID externo ou interno? A replicação proporcionou melhor desempenho, especialmente com leituras de consultas grandes?

Que outras configurações/alterações você fez para melhorar o desempenho do MySQL?

Nota: Eu sei que eles dependem muito do uso (ou seja, pequeno site vs data warehouse), mas como eu acho que a maioria de nós provavelmente trabalha em uma variedade de sites/sistemas, é bom saber uma variedade de técnicas que podem se aplicar a diferentes situações. Além disso, acho que algumas técnicas podem ser transferidas entre as situações.

29
Darryl Hein

Aqui estão minhas recomendações (sua quantidade pode variar)

  • Use RAID de hardware. Isso vai contra minhas recomendações de usar RAID por software em outras postagens, no entanto, esta é uma situação específica em que você quer a placa RAID de hardware. Especificamente, você deseja que a NVRAM com bateria na placa RAID reduza o tempo para fazer o fsync do arquivo de log no disco.
  • Use SOMENTE volumes RAID 1 ou RAID 10. O custo de RAID 5 ou 6 gravações é muito alto para tolerar em uma carga de trabalho mista de leitura/gravação.
  • Use LUNs separados para os volumes de dados, log e tmp. Todos eles devem ser separados do SO e dos volumes de troca.
  • Use InnoDB .
  • Use innodb_file_per_table
  • Use um sistema operacional de 64 bits
  • Defina seu pool de buffer InnoDB para ~ 80% de sua RAM disponível
  • Defina seus arquivos de log para 1/4 do tamanho do pool de buffer, entre 2 a 4 arquivos de log. Arquivos de log maiores significam tempos de desligamento e recuperação mais lentos, mas permitem que você restaure grandes dumps de banco de dados mais rapidamente.
  • log_slow_queries, log-queries-not-using-indexes, set-variable = long_query_time = 1, investigue cada consulta nesse log, refatore seu esquema para evitar varreduras de tabelas e tabelas tmp sempre que possível.
20
Dave Cheney

Mais uma vez Dave Cheney realmente bateu fora do parque aqui. Eu realmente não posso acrescentar nada à resposta dele à sua pergunta. No entanto, gostaria de destacar o que você não perguntou. Como Jeremy Zawodny e Peter Zaitsev me ensinaram anos atrás, seu ROI pelo tempo gasto rastreando e otimizando consultas ruins irá superar seu ROI pelo tempo gasto fazendo alterações de configuração 10 vezes. Claro, você não quer ter uma configuração ruim, a configuração RAID errada ou RAM insuficiente. Mas, entre as consultas ruins de DBAs MySQL excelentes e até marginais (geralmente de desenvolvedores/frameworks, não o DBA) é uma condição crônica, onde a configuração ruim é suportável uma .

(Procurei por esses adjetivos por um tempo e ainda não estou satisfeito com os que escolhi.)

Gostaria de enfatizar novamente que se seus desenvolvedores estão usando um ORM como aqueles comuns em estruturas como Ruby on Rails e Django, você REALMENTE DEVE monitorar o consultas que atingem seu banco de dados. Quando os desenvolvedores param de pensar em SQL e deixam o banco de dados ser abstraído, isso é realmente desagradável. Eu amo os dois frameworks que acabei de mencionar. (Não me rejeite por falar mal deles.) torna a investigação de consultas muito importante. (Leia: Segurança do trabalho)

11
Bruno Bronosky

Algumas outras coisas (que não foram mencionadas na resposta de Dave Cheney)

  • Tente definir innodb_flush_method como O_DIRECT para evitar buffer duplo de dados. Evite isso se sua placa RAID não tiver um cache de gravação com bateria ou se seus dados estiverem em uma SAN.

  • Também brinque com innodb_thread_concurrency. Acredito que o padrão é 8, mas vale a pena ajustar isso para ver se melhora o desempenho

  • Certifique-se de que o cache de consulta esteja ativado e verifique as estatísticas para ver qual é a taxa de acertos. Se for bom, tente aumentá-lo para ver se melhora a taxa de acerto.

  • Dependendo dos aplicativos executados, você pode alterar o nível de isolamento padrão. O padrão é REPEATABLE_READ, mas READ_COMMITTED pode oferecer melhor desempenho

  • Se suas instruções são principalmente UPDATEs e DELETEs, então você pode tentar preparar o cache no escravo fazendo uma consulta SELECT que retorna o conjunto de resultados que deve ser modificado. Verifique a ferramenta mk-slave-prefetch que fará isso por você

  • Dê uma olhada em outros mecanismos de armazenamento além de MyISAM e InnoDB

4
Nathan

Não posso dizer nada sobre hardware, mas você pode tentar http://blog.mysqltuner.com . É um script Perl que analisa as configurações do MySQL.

Você pode ver um exemplo de saída em http://www.thomas-krenn.com/de/wiki/MySQL_Performance_Tuning#mysqltuner.pl

3
weeheavy

A primeira coisa geral que você deve fazer é examinar os parâmetros de memória. As configurações padrão do MySQL são muito conservadoras. Qualquer que seja o mecanismo usado, provavelmente você precisará aumentar alguns parâmetros de memória em dez ou até cem vezes.

A próxima coisa que você deve fazer é examinar o cache da tabela. O valor padrão é 64, que só é útil se você não tiver mais do que cerca de 60 tabelas. Você vai querer aumentar isso muito.

A terceira coisa que você deve fazer é examinar os parâmetros de thread e conexão. O wait_timeout padrão é extremamente longo para a maioria dos aplicativos baseados na web e pode ser reduzido para algo como 30 segundos. Isso também melhorará o uso da memória, já que o MySQL colherá conexões mais cedo, deixando muito menos em um estado de 'suspensão'.

1
staticsan