O AnalyticDB for MySQL classifica consultas lentas conforme o recurso mais consumido: memória, CPU ou E/S de disco. Cada categoria tem uma métrica principal para monitoramento no recurso de diagnósticos SQL e um conjunto distinto de causas raiz.
Consultas lentas que consomem recursos de memória
Métrica principal: Peak Memory — quantidade máxima de memória que uma consulta utiliza durante a execução. Valores elevados indicam maior consumo de memória.
Para identificar consultas intensivas em memória, use o recurso de diagnósticos SQL para buscar execuções longas e verifique Peak Memory na seção Query Properties ou nos resultados de diagnóstico em diferentes níveis. Para obter detalhes, consulte Visualizar propriedades da consulta e resultados de diagnóstico.
As operações a seguir geralmente causam alto consumo de memória:
|
Causa |
Como consome memória |
|
GROUP BY |
O AnalyticDB for MySQL armazena em cache os valores das colunas referenciadas nas cláusulas GROUP BY. Quanto mais valores únicos essas colunas contiverem, maior será o uso de memória. |
|
JOIN (hash join) |
O AnalyticDB for MySQL mantém os dados de uma tabela em cache na memória para construir a tabela hash. Tabelas maiores em cache resultam em maior consumo de memória. |
|
SORT |
O AnalyticDB for MySQL mantém dados em cache na memória durante a ordenação. Um volume maior de dados para ordenar exige mais memória. |
|
Funções de janela |
O AnalyticDB for MySQL mantém dados em cache na memória ao executar funções de janela. Mais dados de entrada implicam maior uso de memória. Para obter detalhes, consulte Funções de janela. |
Consultas lentas que consomem recursos de CPU
Métrica principal: Time Consumed — duração total da execução de uma consulta. Tempos prolongados indicam maior consumo de CPU.
Para identificar consultas intensivas em CPU, use o recurso de diagnósticos SQL para pesquisar execuções demoradas e verifique Time Consumed na seção Query Properties. Para obter detalhes, consulte Visualizar propriedades da consulta.
Os fatores a seguir costumam provocar alto consumo de CPU:
|
Causa |
Como consome CPU |
|
Condições de filtro não aplicadas à camada de armazenamento |
Por padrão, o AnalyticDB for MySQL cria índices para todas as colunas. O uso de índices na filtragem reduz significativamente a utilização da CPU. Se as condições de filtro não forem aplicadas à camada de armazenamento, os índices não poderão ser utilizados. Para cenários em que essa aplicação não ocorre, consulte Condições de filtro não são aplicadas. |
|
Operações de filtro embutidas em condições de junção |
Quando um filtro faz parte de uma condição de junção em vez de uma cláusula WHERE independente, o AnalyticDB for MySQL junta as duas tabelas primeiro e filtra o resultado depois, sem usar índices. Um conjunto de dados intermediário grande proveniente da junção torna a operação de filtro subsequente intensiva em CPU. |
|
Ausência de condição de junção |
Sem uma condição de junção, o AnalyticDB for MySQL executa um produto cartesiano: o conjunto de resultados terá tantas linhas quanto o produto da contagem de linhas das tabelas esquerda e direita. Produtos cartesianos exigem muito processamento da CPU. |
Consultas lentas que consomem recursos de E/S de disco
Métricas principais: Scanned Rows e Scan Size — quantidade de linhas e volume de dados lidos do disco. Valores altos sinalizam maior carga de E/S de disco.
Para identificar consultas intensivas em E/S, use o recurso de diagnósticos SQL para buscar execuções longas e verifique Scanned Rows e Scan Size na seção Query Properties ou nos resultados de diagnóstico em diferentes níveis. Para obter detalhes, consulte Visualizar propriedades da consulta e resultados de diagnóstico.
As situações a seguir geralmente causam alta E/S de disco:
Condições de filtro correspondem apenas a uma pequena fração dos dados, o que reduz a eficiência do índice e força a leitura de um grande número de entradas de índice.
Condições de filtro não são aplicadas à camada de armazenamento, o que desencadeia uma varredura completa na tabela source.
Embora as condições de filtro sejam aplicadas à camada de armazenamento, seu escopo é amplo, exigindo a varredura de um grande volume de dados.
É necessário verificar muitas partições. Geralmente, mais partições significam mais dados para ler.