PolarDB:Slow SQL

Limites

Cada entrada tem limite máximo de 16 KB. O conteúdo que exceder esse tamanho é truncado.

Procedimento

1. Faça login no console do PolarDB. No painel de navegação à esquerda, clique em Clusters. Selecione a Region onde o cluster está implantado e clique no ID do cluster para acessar a página de detalhes.

2. No painel de navegação à esquerda, escolha Diagnostics and Optimization > Slow SQL.

3. Selecione um intervalo de tempo para visualizar a Slow Log Trend, a Event Distribution, as Slow Log Statistics e os Slow Log Details.

   • No gráfico de Slow Log Trend, selecione um ponto no tempo para visualizar as Slow Log Statistics e os Slow Log Details correspondentes.

     Nota

     Se uma instrução SQL lenta for muito longa para exibição completa, passe o ponteiro do mouse sobre ela para ver a instrução inteira em uma caixa pop-up.

   • Clique na lista suspensa Node ID para visualizar o número de solicitações lentas de cada nó.

   • Na área de Event Distribution, consulte eventos de log lento dentro de um intervalo de tempo especificado. Clique em um evento para ver seus detalhes.

   • Nas abas Slow Query Log Statistics e Slow Query Log Details, clique em para salvar as informações do log de consulta lenta no seu computador.

   • Clique em para acessar o console do OpenAPI Explorer. Os parâmetros selecionados e inseridos são transferidos automaticamente para depuração da API.

   • Na seção Slow Log Statistics, localize o modelo de SQL desejado e clique em Details na coluna Actions para visualizar os detalhes do log de consulta lenta.

   • Na área de Slow Log Details, clique em Optimize ou Throttling na coluna Actions de uma instrução SQL específica para executar a SQL Diagnostic Optimization ou o SQL Throttling.

Perguntas frequentes

• P: Por que não consigo ver dados de log de consulta lenta?

  R: As estatísticas de log de consulta lenta são agregadas por meio de uma janela de computação em tempo real; portanto, os dados mais recentes aparecem com atraso de aproximadamente 3 minutos. Verifique também os seguintes pontos:

  • O recurso de log de consulta lenta está ativado para a instância de banco de dados e o limiar está definido com um valor adequado.

  • Logs de consulta lenta foram gerados dentro do intervalo de tempo selecionado.

  • A conta atual possui permissões de acesso ao DAS para a instância de destino.

• P: Por que algumas instâncias estão destacadas em amarelo?

  R: O destaque em amarelo indica que o usuário RAM não tem permissões de acesso aos dados da instância. Resolva esse problema de uma das seguintes maneiras:

  • Entre em contato com um administrador para conceder permissões de acesso à instância ao usuário RAM.

  • Conceda permissões de Global Group: Recomendamos conceder a permissão DASGlobalGroupAdmin para que o usuário RAM possa criar grupos de usuários conforme necessário e visualizar dados de todas as instâncias às quais tem acesso.

• P: Por que o log de consulta lenta mostra Rows_sent como 0 mesmo quando a consulta retorna dados?

  R: Isso geralmente ocorre quando a aplicação utiliza o modo Server-side Cursor. Nesse modo, uma única instrução SQL é executada em duas fases distintas:

  • Fase EXECUTE: O servidor executa a consulta e gera o conjunto de resultados, mas não envia imediatamente as linhas de dados ao cliente. Apenas metadados, como definições de colunas, são retornados.

  • Fase FETCH: O cliente recupera as linhas de dados em lotes por meio de comandos FETCH.

  O log de consulta lenta registra estatísticas apenas da fase EXECUTE. Durante essa fase, o MySQL já examinou os dados (portanto, Rows_examined é diferente de zero), mas nenhuma linha foi enviada ao cliente ainda, pois as linhas são entregues na fase FETCH subsequente. É por isso que Rows_sent é registrado como 0.

  Cenários comuns que desencadeiam esse comportamento:

  • Java/JDBC: A URL de conexão inclui useCursorFetch=true e PreparedStatement.setFetchSize() está definido com um valor maior que 0 ou Integer.MIN_VALUE.

  • Python: A aplicação utiliza MySQLdb.cursors.SSCursor ou pymysql.cursors.SSCursor.

  • Frameworks ORM: Alguns frameworks ORM usam consultas em streaming por padrão para grandes conjuntos de resultados. Consultas em streaming utilizam o modo Cursor internamente.

  Para confirmar se essa é a causa, verifique se o código da sua aplicação configura um fetchSize ou utiliza um cursor de streaming. Também é possível executar SHOW GLOBAL STATUS LIKE 'Com_stmt_fetch'; no banco de dados para verificar se solicitações FETCH estão sendo emitidas.

• P: Por que o horário de conclusão da execução registrado no log de consulta lenta difere do tempo real de execução da instrução SQL?

  R: Isso normalmente acontece quando uma instrução SQL executada modifica o fuso horário. O carimbo de data/hora em um log de consulta lenta pode ser baseado no fuso horário no nível da sessão, do banco de dados ou do sistema. O log utiliza o fuso horário definido no nível do banco de dados ou recorre ao fuso horário do sistema caso nenhum esteja configurado. Se uma instrução SQL alterar o fuso horário no nível da sessão, o carimbo de data/hora no log pode não ser convertido corretamente, resultando em uma discrepância.

API relacionada