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

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

Estou me perguntando sobre as melhorias reais do arquivo de configuração, tipos de tabelas, configurações de hardware, replicação etc. Qualquer coisa que não seja a estrutura de consultas e a estrutura de tabelas (são fáceis de encontrar no site e no Stack Overflow). São as coisas como configurações de cache de consulta que deram a você mais velocidade? Que tal unidades; é melhor tê-lo em um RAID externo ou interno? A replicação ofereceu melhor desempenho, especialmente com consultas grandes de leitura?

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

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

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

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

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

(Eu pesquisei 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 os comuns em estruturas como Ruby on Rails e Django, você REALMENTE DEVE monitorar as consultas que atingem seu banco de dados. Quando os desenvolvedores param de pensar em SQL e deixam o banco de dados abstraído, isso é realmente desagradável. Eu amo as duas estruturas que acabei de mencionar. (Não vote em mim por ofensas ruins.) Isso apenas torna o Query Sleuthing muito importante. (Leia: Segurança no Trabalho)

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

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

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

• Verifique se o cache da consulta está 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 acertos.

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

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

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

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

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

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

A próxima coisa que você deve fazer é olhar para o cache da tabela. O valor padrão é 64, o que é útil apenas se você tiver no máximo 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, pois o MySQL colherá conexões mais cedo, deixando muito menos em um estado de 'suspensão'.