[ad_1]
As consultas inesperadamente lentas são um dos problemas de desempenho mais comuns do MySQL. Uma consulta com desempenho decente no desenvolvimento pode falhar quando pressionada por uma carga de trabalho de produção.
Aplicativos grandes podem executar centenas de consultas de banco de dados exclusivas sempre que um endpoint é alcançado. Isso dificulta a identificação das consultas que estão causando atrasos na resposta do servidor. O log de consultas lentas do MySQL é uma opção de depuração que pode ajudá-lo a identificar instruções SQL suspeitas, fornecendo um ponto de partida para suas investigações.
Ativando o registro de consultas lentas
Logging é um mecanismo interno para registrar consultas SQL de longa duração. As consultas que não forem concluídas dentro de um tempo configurado serão gravadas no log. A leitura do conteúdo do log mostra o SQL que foi executado e quanto tempo demorou.
O log de consultas lentas está desabilitado por padrão. Você pode ativá-lo em seu servidor executando o seguinte comando em um shell administrativo do MySQL:
SET GLOBAL slow_query_log_file="/var/log/mysql/mysql-slow.log";
SET GLOBAL slow_query_log=1;
A alteração é aplicada imediatamente. As consultas lentas agora serão registradas em /var/log/mysql/mysql-slow.log
. Você pode revisar esse arquivo periodicamente para identificar consultas com desempenho insatisfatório.
O MySQL conta uma consulta como “lenta” se levar mais de 10 segundos para ser concluída. Esse limite geralmente é muito relaxado para aplicativos da Web voltados para o usuário em que são esperadas respostas quase instantâneas. Você pode alterar o limite configurando o long_query_time
variável:
SET GLOBAL long_query_time=1;
O valor define a duração mínima para consultas lentas. É importante encontrar um equilíbrio que se adapte à sua própria aplicação. Um limite muito alto excluirá consultas que realmente afetam o desempenho. Por outro lado, valores muito baixos podem fazer com que muitas consultas sejam capturadas, criando um log excessivamente barulhento.
Usando o arquivo de configuração do MySQL
Você deve habilitar o log de consultas lentas em seu arquivo de configuração do MySQL se planeja usá-lo a longo prazo. Isso garantirá que o registro seja retomado automaticamente depois que o servidor MySQL for reiniciado.
A localização do arquivo de configuração pode variar dependendo da distribuição da plataforma. geralmente é em /etc/mysql/my.cnf
qualquer /etc/mysql/mysql.conf.d/mysqld.cnf
. Adicione as seguintes linhas para replicar as configurações que foram habilitadas dinamicamente acima:
slow_query_log=1 slow_query_log_file=/var/log/mysql/mysql-slow.log long_query_time=1
Reinicie o MySQL para aplicar suas alterações:
$ sudo service mysql restart
O log de consultas lentas agora estará ativo toda vez que o servidor MySQL for iniciado.
Personalizando o conteúdo do log
O log normalmente inclui apenas consultas SQL que excluem o limite “lento” e que foram enviadas por aplicativos cliente. Isso exclui quaisquer operações administrativas lentas que possam ocorrer, como criação de índice e otimização de tabela, bem como consultas que tenham o potencial ser lento no futuro.
Você pode estender o registro para incluir essas informações fazendo as seguintes alterações em seu arquivo de configuração:
log_slow_admin_statements = 1
– Inclui instruções SQL administrativas, comoALTER TABLE
,CREATE INDEX
,DROP INDEX
SOPTIMIZE TABLE
. Isso raramente é desejável, pois essas operações geralmente são executadas durante os scripts de manutenção e migração. No entanto, essa configuração pode ser útil se seu aplicativo também executar essas tarefas dinamicamente.log_slow_replica_statements = 1
– Essa configuração habilita o log de consultas lentas para consultas replicadas em servidores de réplica. Isso está desabilitado por padrão. Usarlog_slow_slave_statements
em vez disso, para o MySQL versões 8.0.26 e anteriores.log_queries_not_using_indexes = 1
– Quando essa configuração estiver habilitada, as consultas que devem recuperar todos os registros da tabela ou exibição de destino serão registradas, mesmo que não excluam o limite de consulta lenta. Isso pode ajudar a identificar quando uma consulta não tem um índice ou não pode usá-lo. As consultas que têm um índice disponível ainda serão registradas se não tiverem restrições que limitem o número de linhas buscadas.
As consultas de log que não usam índices podem aumentar significativamente a verbosidade. Pode haver situações em que uma verificação completa do índice seja esperada ou necessária. Essas consultas continuarão a aparecer no log mesmo que não possam ser resolvidas.
Você pode qualificar consultas de limite sem índices definindo o log_throttle_queries_not_using_indexes
variável. Isso define o número máximo de registros que serão escritos em um período de 60 segundos. um valor de 10
significa que até 10 consultas por minuto serão registradas. Após o 10º evento, nenhuma consulta será registrada até que a próxima janela de 60 segundos seja aberta.
Interpretação do registro de consulta lenta
Cada consulta que atinge o log de consultas lentas exibirá um conjunto de linhas semelhante ao seguinte:
# Time: 2022-07-12T19:00:00.000000Z # [email protected]: demo[demo] @ mysql [] Id: 51 # Query_time: 3.514223 Lock_time: 0.000010 Rows_sent: 5143 Rows_examined: 322216 SELECT * FROM slow_table LEFT JOIN another_table ...
As linhas comentadas na consulta contêm a hora em que ela foi executada, o usuário MySQL com o qual o cliente se conectou e estatísticas que fornecem a duração e o número de linhas enviadas. O exemplo acima levou 3,5 segundos para ser concluído e analisou mais de 320.000 linhas, antes de enviar apenas 5.143 para o cliente. Isso pode ser uma indicação de que índices ausentes estão fazendo com que o MySQL inspecione muitos registros.
Opcionalmente, você pode incluir mais informações no log definindo o log_slow_extra = 1
variável do sistema em seu arquivo de configuração. Isso agregará o ID do thread, o número de bytes recebidos e enviados e o número de linhas consideradas para classificação, bem como contagens de solicitações específicas de instruções que fornecem visibilidade de como o MySQL lidou com a consulta.
O arquivo de log deve ser tratado com cuidado, pois seu conteúdo será confidencial. As consultas são exibidas em sua totalidade, sem mascarar os valores dos parâmetros. Isso significa que os dados do usuário estarão presentes se você estiver usando o log de consulta lento em um servidor de produção. O acesso deve ser restrito a desenvolvedores e administradores de banco de dados que estão ajustando instruções SQL.
Registro lento de consultas e backups
Uma frustração comum com o log de consultas lento surge quando você também usa o MySQLDump para criar backups de banco de dados. de longa duração SELECT * FROM ...
consultas serão executadas para obter os dados de suas tabelas e alimentá-los em seu backup. Eles serão registrados para consultas lentas como qualquer outra instrução SQL. Isso pode contaminar o registro se você fizer backups regulares.
Você pode corrigir isso desativando temporariamente o registro de consultas lentas antes de executar mysqldump
. Você pode reativar o registro após a conclusão do backup. Ajuste seu script de backup para se parecer com o seguinte:
#!/bin/bash # Temporarily disable slow query logging mysql -uUser -pPassword -e "SET GLOBAL slow_query_log=0"; # Run mysqldump mysqldump -uUser -pPassword --single-transaction databaseName | gzip > backup.bak # Enable the slow query log again mysql -uUser -pPassword -e "SET GLOBAL slow_query_log=1"
Isso manterá a atividade do MySQLDump fora do log de consultas lentas, facilitando o foco no SQL que seu aplicativo executa.
Resumo
O log de consultas lentas do MySQL é uma das maneiras mais eficazes de identificar a causa dos problemas de desempenho. Comece estimando o atraso que você está enfrentando e use esse valor como seu long_query_time
. Reduza o valor se nada aparecer no log depois de reproduzir o problema.
O log de consulta lenta não informará exatamente como corrigir a lentidão. No entanto, a capacidade de ver o SQL exato recebido pelo servidor permite iterar instruções com desempenho insatisfatório e, em seguida, medir o efeito das otimizações. Adicionar um índice ou restrição ausente pode ser a diferença entre uma consulta que toca milhares de linhas e uma que funciona com um punhado.
[ad_2]