A má notícia:existem ferramentas GUI para ajudar com isso, mas é um trabalho qualificado e abrangente. Portanto, eles não cobrem tudo, é provável que você precise usar instruções de linha de comando/sql etc para ajudar. Eu realmente só usei as ferramentas de linha de comando. Vou dar um pouco de uma visão geral das coisas que eu sei / usei:

Primeiro, você precisa de um bom design de banco de dados. Se o design for ruim, você só pode chegar até aqui. Isso inclui a normalização, bem como o uso de tipos apropriados para campos. Vou deixar este ponto aqui, pois acho que é um pouco de lado, e não o que você está procurando.

Certifique-se de que o MySQL Query Cache está configurado e funcionando e dê a ele um pouco mais de RAM se puder, e certifique-se de que suas consultas importantes não estejam fazendo nada que impeça o mysql de armazená-las em cache. Por exemplo, usar a função NOW() em consultas faz isso - por razões óbvias - NOW muda a cada segundo! Em vez disso, você pode colocar um timestamp no sql e usar o tempo para o minuto/hora/dia mais próximo (o maior período que você pode usar) para permitir que o mysql obtenha algum benefício de cache.

Para começar a otimizar as coisas:Colocar "EXPLAIN" na frente de select é A maneira de ver como uma consulta está sendo executada e identificar como melhorá-la. Aprenda a interpretar a saída:http://dev.mysql .com/doc/refman/5.0/en/using-explain.html Muitas vezes, você poderá adicionar novos índices/colunas aos existentes para melhorar as coisas. Mas você também encontrará momentos em que as consultas precisam ser reestruturadas.

Começar a melhorar o desempenho com o MySQL (supondo que você ainda não saiba qual é a consulta do problema) é verificar o log de consulta lenta - ele registra em um arquivo todas as consultas que levam mais de x segundos.

A visão geral, incluindo a configuração para se ainda não estiver registrando, está aqui:http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html - Também descobri que definir long_query_time como 0 por um dia ou mais, para que todas as consultas sejam registradas aqui com o tempo gasto, é uma maneira útil de ter uma ideia exata de onde o desempenho está indo. Mas eu não iria lá imediatamente! E não o deixe ligado, os logs podem ficar enormes.

Depois de alguns dias de registro, encontrei o mysqlsla (analisador de log lento do mysql) aqui:http://hackmysql.com/mysqlsla é uma boa ferramenta.

Ele pode fazer mais do que apenas uma análise lenta do log de consultas - leia o manual. Mas para explicar o que ele faz para logs lentos:o log de consulta lenta pode conter muitos dados, portanto, pode ser difícil descobrir quais consultas são as mais caras em geral - por exemplo:fatorar quantas vezes elas são executadas e quando duas consultas são realmente os mesmos com um id diferente em uma cláusula where.

O MySQL sla faz tudo isso para você. Ele é executado no log e pode agrupar consultas iguais/com valores diferentes nas cláusulas where. Em seguida, ele apresenta (por padrão) as 10 principais consultas em termos de tempo total de execução - o que geralmente traz algumas surpresas, mas geralmente é o ponto de partida mais produtivo - pegue a consulta mais cara e use EXPLAIN nela e veja se você pode melhorar isto.

Algumas consultas demoram muito e não podem ser melhoradas facilmente. Nesse caso, você pode obter os dados de outra maneira ou pelo menos armazená-los em cache? Você pode até achar que é necessário alterar o esquema do banco de dados. Da mesma forma, algumas consultas podem estar no topo da saída do mysqlsla porque você as executa muito (especialmente verdadeiro se long_query_time estiver definido como 0), mesmo que elas sejam executadas muito rapidamente. Talvez seja hora de adicionar algum cache ao seu aplicativo?

http://www.maatkit.org/ também parece promissor - nunca a usei, mas a ferramenta mk-query-profiler deve ser útil para investigar melhor por que as consultas ficam lentas.

Uma coisa completamente separada para olhar também:a página de "status" no PHPMYADMIN (ou você pode executar todas as consultas para gerar essa informação ....) - destaca as coisas que acha que podem estar ruins em vermelho e pode ajudá-lo veja onde você pode se beneficiar da alocação de recursos do sistema. Eu não sei muito sobre isso - minha abordagem sempre foi que, se algo está vermelho e parece ruim, ler sobre isso e decidir se é importante e se devo fazer algo (geralmente significa alocar mais recursos ao MySQL alterando a configuração).

Recentemente descobri que executar SHOW PROCESSLIST também pode ser útil em um servidor que está sofrendo. Embora apenas forneça informações ao vivo (bem, um instantâneo ao vivo), ele pode ajudá-lo a ter uma ideia do que está acontecendo em um determinado momento, especialmente se você atualizar algumas vezes e observar as alterações. Recentemente, localizei um servidor usando todas as conexões mysql disponíveis para executar uma consulta idêntica usando esse método. Claro, estaria no log de consultas lentas, mas isso é uma maneira realmente rápida e óbvia de ver o que estava acontecendo.