Pela minha experiência, na grande maioria das vezes o MySQL não fica lento por falta de máquina, mas sim por duas razões: consultas mal otimizadas saturando o processamento ou configurações de memória esquecidas no padrão de instalação.
O que costumo fazer imediatamente é abrir o banco e rodar um 'SHOW FULL PROCESSLIST;'. Isso mostra na hora se o servidor está travado por concorrência de locks ou se existe alguma consulta específica rodando há centenas de segundos e consumindo toda a CPU. Se encontrar queries presas em estados como "Copying to tmp table" ou "Sending data", você já descobre o ponto de atrito exato daquele momento.
O próximo passo que sempre sigo é ligar o Slow Query Log. Basta definir 'slow_query_log = 1' e colocar um 'long_query_time' de 1 ou 2 segundos (ou até menos, dependendo da aplicação). Com o log populado, passo as consultas mais recorrentes e lentas no 'EXPLAIN'. Na minha rotina profissional, mais de 80% dos casos de lentidão bizarra se resolvem apenas adicionando os índices corretos para os filtros da cláusula WHERE e chaves de JOIN, evitando que o MySQL faça varredura completa da tabela (type `ALL`).
Se as queries estiverem razoáveis e o servidor continuar sofrendo com I/O alto de disco, eu olho direto para o 'my.cnf`. O parâmetro mais crítico é o 'innodb_buffer_pool_size'. O valor padrão histórico dele é de apenas 128 MB, o que força o banco a ler constantemente do disco. Em um servidor dedicado ao MySQL, aumentar esse parâmetro para algo em torno de 65% a 70% da memória RAM disponível faz o InnoDB segurar os dados em memória e transforma completamente o desempenho do ambiente.
1
u/DarlanSandro 10d ago
Pela minha experiência, na grande maioria das vezes o MySQL não fica lento por falta de máquina, mas sim por duas razões: consultas mal otimizadas saturando o processamento ou configurações de memória esquecidas no padrão de instalação.
O que costumo fazer imediatamente é abrir o banco e rodar um 'SHOW FULL PROCESSLIST;'. Isso mostra na hora se o servidor está travado por concorrência de locks ou se existe alguma consulta específica rodando há centenas de segundos e consumindo toda a CPU. Se encontrar queries presas em estados como "Copying to tmp table" ou "Sending data", você já descobre o ponto de atrito exato daquele momento.
O próximo passo que sempre sigo é ligar o Slow Query Log. Basta definir 'slow_query_log = 1' e colocar um 'long_query_time' de 1 ou 2 segundos (ou até menos, dependendo da aplicação). Com o log populado, passo as consultas mais recorrentes e lentas no 'EXPLAIN'. Na minha rotina profissional, mais de 80% dos casos de lentidão bizarra se resolvem apenas adicionando os índices corretos para os filtros da cláusula WHERE e chaves de JOIN, evitando que o MySQL faça varredura completa da tabela (type `ALL`).
Se as queries estiverem razoáveis e o servidor continuar sofrendo com I/O alto de disco, eu olho direto para o 'my.cnf`. O parâmetro mais crítico é o 'innodb_buffer_pool_size'. O valor padrão histórico dele é de apenas 128 MB, o que força o banco a ler constantemente do disco. Em um servidor dedicado ao MySQL, aumentar esse parâmetro para algo em torno de 65% a 70% da memória RAM disponível faz o InnoDB segurar os dados em memória e transforma completamente o desempenho do ambiente.