Melhoria do performance de consultas do

Seguem alguns problemas comuns que afetam a performance da consulta, com instruções sobre maneiras de diagnosticá-los e resolvê-los.

Estatísticas de tabela ausentes ou desatualizadas

Se estatísticas da tabela estiverem ausentes ou desatualizadas, você pode ver o seguinte:

• Uma mensagem de advertência nos resultados do comando EXPLAIN.

• Um evento de alerta de estatísticas ausentes em STL_ALERT_EVENT_LOG. Para ter mais informações, consulte Revisar alertas da consulta.

Para corrigir esse problema, execute ANALYZE.

Loop aninhado

Se um loop aninhado estiver presente, você poderá ver um evento de alerta de loop aninhado em STL_ALERT_EVENT_LOG. Você também pode identificar esse tipo de evento ao executar a consulta em Como identificar consultas com loops aninhados. Para ter mais informações, consulte Revisar alertas da consulta.

Para corrigir isso, revise sua consulta para junções cruzadas e remova-as, se possível. Junções cruzadas sem uma condição de junção que resulte no produto cartesiano de duas tabelas. São tipicamente executadas como junções de loops aninhados, que são os mais baixos dos possíveis tipos de junção.

Junção de hash

Se uma junção hash estiver presente, você poderá ver o seguinte:

• Operações de hash e de junções hash no plano de consulta. Para ter mais informações, consulte Analisar o plano de consulta.

• Uma etapa HJOIN no segmento com o valor mais alto de maxtime em SVL_QUERY_SUMMARY. Para ter mais informações, consulte Usar a visualização SVL_QUERY_SUMMARY.

Para corrigir esse problema, há duas opções de abordagem:

• Reescreva a consulta para usar uma junção de mesclagem, se possível. Você pode fazer isso especificando as colunas de junção que são tanto chaves de distribuição quanto chaves de classificação.

• Se uma etapa HJOIN em SVL_QUERY_SUMMARY tiver um valor muito elevado no campo de linhas comparado ao valor de linhas na etapa final de RETURN da consulta, verifique se você pode reescrever a consulta para junção em uma coluna exclusiva. Quando a junção de uma consulta não ocorre em uma coluna exclusiva, tal como a chave primária que aumenta o número de linhas envolvidas na junção.

Linhas fantasmas ou linhas não confirmadas

Se linhas fantasmas ou linhas não confirmadas estiverem presentes, você poderá ver um evento de alerta em STL_ALERT_EVENT_LOG que indicará linhas fantasmas excessivas. Para ter mais informações, consulte Revisar alertas da consulta.

Para corrigir esse problema, há duas opções de abordagem:

• Verifique a guia Carregamentos do console do Amazon Redshift para operações de carregamento ativo em qualquer uma das tabelas de consulta. Se você vir operações de carregamento ativas, aguarde a conclusão destas operações antes de realizar uma ação.

• Se não houver operações de carregamento ativas, execute VACUUM nas tabelas da consulta para remover as linhas excluídas.

Linhas não classificadas ou mal classificadas

Se linhas não classificadas ou mal classificadas estiverem presentes, você poderá ver um evento alerta de filtro muito seletivo em STL_ALERT_EVENT_LOG. Para ter mais informações, consulte Revisar alertas da consulta.

Você também pode verificar se uma das tabelas em sua consulta tem grandes áreas não classificadas ao executar a consulta em Identificar tabelas com desvio de dados ou linhas não classificadas.

Para corrigir esse problema, há duas opções de abordagem:

• Execute VACUUM nas tabelas da consulta para reclassificar as linhas.

• Revise as chaves de classificação nas tabelas da consulta para ver se melhorias podem ser feitas. Lembre-se de considerar a performance desta consulta em relação à performance de outras consultas importantes, além do sistema de forma geral antes de fazer quaisquer alterações. Para ter mais informações, consulte Trabalhar com chaves de classificação.

Distribuição de dados pouco satisfatória

Se a distribuição de dados for pouco satisfatória, você poderá ver o seguinte:

• Uma execução em série, uma grande transmissão ou um evento de alerta de grande distribuição aparece em STL_ALERT_EVENT_LOG. Para ter mais informações, consulte Revisar alertas da consulta.

• Fatias não estão processando, aproximadamente, o mesmo número de linhas para uma determinada etapa. Para ter mais informações, consulte como usar a visualização SVL_QUERY_REPORT.

• Fatias não estão utilizando, aproximadamente, a mesma quantidade de tempo para determinada etapa. Para ter mais informações, consulte como usar a visualização SVL_QUERY_REPORT.

Se nenhuma das condições anteriores for verdadeira, você também poderá ver se alguma das tabelas em sua consulta possui desvio de dados ao executar a consulta em Identificar tabelas com desvio de dados ou linhas não classificadas.

Para corrigir esse problema, analise os estilos de distribuição das tabelas da consulta e veja se é possível realizar alguma melhoria. Lembre-se de considerar a performance desta consulta em relação à performance de outras consultas importantes, além do sistema de forma geral antes de fazer quaisquer alterações. Para ter mais informações, consulte Trabalhar com estilos de distribuição de dados.

Memória insuficiente alocada para a consulta

Se a memória alocada for insuficiente para sua consulta, você poderá ver uma etapa em SVL_QUERY_SUMMARY que terá um valor is_diskbased verdadeiro. Para ter mais informações, consulte Usar a visualização SVL_QUERY_SUMMARY.

Para corrigir esse problema, aloque mais memória para a consulta temporariamente aumentando o número de vagas de consulta que ela utiliza. O gerenciamento de workload (WLM) reserva vagas em uma fila de consulta equivalente ao nível de simultaneidade definido para a fila. Por exemplo, uma fila com um nível de simultaneidade de 5 tem 5 vagas. A memória atribuída à fila é alocada igualmente a cada vaga. A atribuição de várias vagas para uma consulta dá a ela acesso à memória de todas as outras vagas. Para obter mais informações sobre como aumentar as vagas temporariamente para uma consulta, veja wlm_query_slot_count.

Cláusula WHERE pouco satisfatória

Se sua cláusula WHERE causar varreduras excessivas da tabela, talvez você veja uma etapa SCAN no segmento com o maior valor maxtime em SVL_QUERY_SUMMARY. Para ter mais informações, consulte Usar a visualização SVL_QUERY_SUMMARY.

Para corrigir esse problema, adicione uma cláusula WHERE à consulta com base na coluna de classificação principal da maior tabela. Essa abordagem ajuda a minimizar o tempo de varredura. Para ter mais informações, consulte Práticas recomendadas do Amazon Redshift para projetar tabelas.

Predicado insuficientemente restritivo

Se sua consulta tem um predicado insuficientemente restritivo, você pode ver uma etapa SCAN no segmento com o maior valor maxtime em SVL_QUERY_SUMMARY que tem um valor de rows muito alto comparado ao valor de rows na etapa final de RETURN da consulta. Para ter mais informações, consulte Usar a visualização SVL_QUERY_SUMMARY.

Para corrigir esse problema, tente adicionar um predicado à consulta ou tornar o predicado existente mais restritivo para restringir a saída.

Conjunto de resultados muito grande

Se sua consulta retornar um conjunto de resultados muito grande, considere reescrever a consulta para usar UNLOAD para gravar os resultados no Amazon S3. Essa abordagem melhorará a performance da etapa final de RETURN aproveitando o processamento paralelo. Para obter mais informações sobre a verificação da existência de um conjunto muito grande de resultados, consulte Usar a visualização SVL_QUERY_SUMMARY.

Lista SELECT grande

Se sua consulta tiver uma lista SELECT inesperadamente grande, você poderá ver um valor bytes alto em relação ao valor de rows para qualquer etapa (em comparação às outras etapas) em SVL_QUERY_SUMMARY. Este valor bytes alto pode ser um indicador de que você está selecionando muitas colunas. Para ter mais informações, consulte Usar a visualização SVL_QUERY_SUMMARY.

Para corrigir esse problema, revise as colunas que você está selecionando e verifique se alguma pode ser removida.