Resultados de diagnóstico no nível de operador - AnalyticDB: Central de Documentação do Alibaba Cloud

O recurso de diagnóstico de SQL do AnalyticDB for MySQL coleta estatísticas de consultas SQL nos níveis de consulta, estágio e operador. O sistema usa essas estatísticas para fornecer diagnósticos e sugestões de otimização. Este tópico descreve como visualizar e analisar os resultados de diagnóstico no nível de operador.

Tipos de resultados de diagnóstico

Nota

Para mais informações, consulte

Visualize diagnostic results

Low aggregation degree for an aggregation operator
Filter conditions are not pushed down
Data bloat in a Join operation
The right table in a Join operation is too large
A Cross Join operation exists
A scan operator reads too many fields
Data skew in a table scan
Inefficient index

Baixo grau de agregação em um operador de agregação

Problema

O grau de agregação de um operador corresponde à razão entre o volume de dados de entrada (InputDataSize) e o volume de dados de saída (OutputDataSize) em uma operação GROUP BY. Uma razão menor indica menor grau de agregação e eficácia reduzida. No AnalyticDB for MySQL, as operações de agrupamento e agregação ocorrem em duas etapas: agregação parcial (PARTIAL) e agregação final (FINAL). Se um operador de agregação tiver muitos grupos, o grau de agregação será baixo. Consequentemente, a etapa de agregação parcial não reduz a transferência de dados pela rede e consome muitos recursos de computação.
Sugestão

Considere ignorar a etapa de agregação parcial. Redistribua os dados entre os nós e execute apenas uma agregação final. Para mais informações, consulte Optimize grouping and aggregation queries.

Condições de filtro não aplicadas por pushdown

Problema
O AnalyticDB for MySQL

cria um índice para cada campo da tabela durante o armazenamento de dados. Esses índices aceleram a filtragem nas consultas. Contudo, o

AnalyticDB for MySQL

não aplica pushdown nas condições de filtro nos seguintes cenários:
- O recurso de pushdown de condição de filtro está desativado porque a instrução de consulta usa a hint no_index_columns ou filter_not_pushdown_columns, ou porque o cluster utiliza a configuração adb_config filter_not_pushdown_columns.
- A condição de filtro utiliza uma função, como o operador cast.
- O campo relevante na condição de filtro não possui índice. Isso ocorre se a palavra-chave no_index foi especificada durante a criação da tabela ou se o índice foi excluído pela execução de DROP INDEX posteriormente.
Sugestão
- Se o pushdown de condição de filtro estiver desativado devido a uma hint na instrução de consulta ou a uma configuração do cluster, investigue o motivo e verifique a possibilidade de remoção. Para mais informações, consulte Do not push down filter conditions.
- Caso haja uso de função, considere aplicá-la durante a gravação dos dados e remova-a da consulta.
- Se as condições de filtro não forem aplicadas por pushdown devido à ausência de índice no campo relevante, investigue o motivo da falta do índice.

Inflação de dados em uma operação Join

Problema

A taxa de inflação de dados em uma operação Join é a razão entre o número de linhas de saída e o de entrada. O total de linhas de entrada corresponde à soma das linhas das tabelas esquerda e direita. Com uma condição de junção adequada, o número de linhas de saída costuma ser menor que o de entrada. Se as linhas de saída superarem as de entrada, ocorre inflação de dados. Esse fenômeno consome grandes quantidades de recursos de computação e memória, tornando a consulta mais lenta.
Sugestão
- Se a inflação de dados resultar das características dos dados, como a existência de muitos valores idênticos em ambas as tabelas, filtre esses valores durante a etapa de filtragem da tabela para excluí-los da operação Join.
- Caso a inflação decorra de uma ordem de junção subótima, ajuste manualmente essa ordem. Para mais informações, consulte Manually adjust the join order.

Tabela direita muito grande em uma operação Join

Problema
No

AnalyticDB for MySQL

, a tabela direita de uma operação Join geralmente atua como tabela builder, responsável por criar uma estrutura de hash ou conjunto na memória. Uma tabela direita grande pode consumir recursos de memória excessivos e comprometer a estabilidade geral do cluster. Os motivos para a tabela direita ser grande demais incluem:
- A instrução SQL contém um Left Join. Durante a execução, a tabela direita de um Left Join deve obrigatoriamente ser a tabela builder. Portanto, se essa tabela for grande, o consumo de memória será elevado.
- O AnalyticDB for MySQL estimou incorretamente o volume de dados das tabelas esquerda e direita. Fatores como estatísticas desatualizadas podem causar esse erro.
Sugestão

Para otimizar, reescreva o Left Join como Right Join. Para mais informações, consulte Rewriting a Left Join as a Right Join.

Existência de operação Cross Join

Problema

Um Cross Join é uma operação de junção sem condição de associação. O número de linhas de saída equivale ao produto do número de linhas das tabelas esquerda e direita. Se ambas as tabelas forem grandes, um Cross Join pode afetar gravemente a estabilidade do cluster AnalyticDB for MySQL.
Sugestão

Adicione uma condição de junção para eliminar o Cross Join.

Operador de leitura acessando campos em excesso

Problema

Um operador de leitura filtra e lê dados detalhados da camada de armazenamento do AnalyticDB for MySQL. Se uma instrução SELECT incluir muitos campos, será necessário ler um grande volume de dados detalhados. Isso consome recursos significativos de I/O de disco e afeta a estabilidade geral do cluster AnalyticDB for MySQL.
Sugestão

Otimize a instrução SQL para remover campos desnecessários da instrução SELECT.

Skew de dados na leitura de tabela

Problema

O AnalyticDB for MySQL utiliza uma arquitetura de execução distribuída. Para tabelas grandes, especifique uma chave de distribuição. Durante a gravação, os dados são distribuídos entre diferentes nós de armazenamento com base nessa chave. Se os valores da chave de distribuição forem desiguais, os dados também ficarão armazenados de forma desigual nos nós. Isso gera um efeito de longa cauda durante a leitura, em que alguns nós demoram muito mais que outros. Tal desequilíbrio prejudica o desempenho da consulta.
Sugestão

Reduza o skew de dados nas leituras de tabela selecionando uma chave de distribuição adequada. Para mais informações sobre métodos de otimização, consulte Storage space diagnosis.

Índice ineficiente

Problema

Quando o AnalyticDB for MySQL usa um índice para filtragem de dados, o desempenho pode ficar abaixo do esperado se a seletividade do campo filtrado for baixa. A seletividade é a razão entre o volume de dados de saída e o volume de dados de entrada do operador de filtro.
Sugestão

Considere não aplicar pushdown nas condições de filtro. Em vez disso, execute a filtragem diretamente nos nós de computação. Para mais informações, consulte Do not push down filter conditions.