Resolver problemas de regressões de desempenho de consultas

Nesta página, explicamos como detectar mudanças na velocidade de execução de consultas, inspecionar planos de execução de consultas e especificar um índice diferente para consultas futuras, se necessário.

Obtenha o perfil detalhado de uma consulta no formato JSON usando a API REST

Por padrão, quando você executa uma consulta, a API retorna apenas os resultados da instrução. Isso ocorre porque queryMode está definido como NORMAL. Para incluir estatísticas de execução detalhadas nos resultados da consulta, defina queryMode como PROFILE.

Criar uma sessão

Antes de atualizar o modo de consulta, crie uma sessão, que representa um canal de comunicação com o serviço de banco de dados do Spanner.

  1. Acesse a página projects.instances.databases.sessions.create.

  2. Informe o ID do projeto, o ID da instância e o ID do banco de dados no seguinte formato:

    projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID

  3. Clique em Executar. A resposta mostra a sessão que você criou neste formulário:

    projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID/sessions/SESSION_ID

    Use essa sessão para analisar a consulta na próxima etapa. Uma sessão permanece ativa por até uma hora entre usos consecutivos antes que o Spanner a exclua.

Para mais informações sobre como usar sessões, consulte Sessões.

Definir o perfil da consulta

Habilitar PROFILE para a consulta.

  1. Acesse a página projects.instances.databases.sessions.executeSql.

  2. Em session, insira o ID da sessão que você criou em Criar uma sessão:

    projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID/sessions/SESSION_ID

  3. Para o Corpo de solicitação, use o seguinte:

    { "sql": "SQL_QUERY", "queryMode": "PROFILE" }

  4. Clique em Executar. A resposta inclui os resultados da consulta, o plano de consulta e as estatísticas de execução da consulta.

Resolver problemas de uso do índice

Quando você usa consultas SQL para procurar dados, o Spanner utiliza automaticamente todos os índices secundários que provavelmente recuperarão os dados com mais eficiência. No entanto, em alguns casos, o Spanner pode escolher um índice que deixa as consultas mais lentas. Como resultado, talvez você perceba que algumas consultas são executadas mais lentamente do que o esperado.

Detectar mudanças na velocidade de execução de consultas

É mais provável que você veja uma alteração na velocidade de execução da consulta depois de fazer uma destas alterações:

  • Alterar significativamente uma grande quantidade de dados existentes que têm um índice secundário.
  • Como adicionar, alterar ou descartar um índice secundário.

É possível usar várias ferramentas diferentes para identificar uma consulta específica que o Spanner está executando mais lentamente do que o normal:

Estatísticas do otimizador para bancos de dados recém-criados

Ao consultar bancos de dados recém-criados com dados recém-inseridos ou importados, o Spanner pode não selecionar os índices mais apropriados porque o otimizador de consultas leva até três dias para coletar estatísticas automaticamente. Para otimizar o uso do índice de um novo banco de dados do Spanner antes disso, é possível criar manualmente um novo pacote de estatísticas.

Analise o esquema

Depois de localizar a consulta que ficou mais lenta, observe a instrução SQL da consulta e identifique as tabelas usadas pela instrução e as colunas que ela recupera dessas tabelas.

Em seguida, encontre os índices secundários que existem para essas tabelas. Determine se algum dos índices inclui as colunas que você está consultando, o que significa que o Spanner pode usar um dos índices para processar a consulta.

  • Se houver índices aplicáveis, a próxima etapa será encontrar o índice que o Spanner usou para a consulta.

  • Se não houver índices aplicáveis, use o comando gcloud spanner operations list para verificar se você descartou recentemente um índice aplicável:

    gcloud spanner operations list \
    --instance=INSTANCE \
    --database=DATABASE \
    --filter="@TYPE:UpdateDatabaseDdlMetadata"

    Se você descartou um índice aplicável, essa alteração pode ter afetado o desempenho da consulta. Adicione o índice secundário de volta à tabela. Depois que o Spanner adicionar o índice, execute a consulta novamente e observe o desempenho dela. Se o desempenho não melhorar, a próxima etapa é encontrar o índice que o Spanner usou para a consulta.

    Se você não descartou um índice aplicável, a seleção do índice não causou o retorno do desempenho da consulta. Procure outras alterações nos seus dados ou padrões de uso que possam ter afetado o desempenho.

Encontrar o índice usado para uma consulta

Para descobrir qual índice o Spanner está usando para processar uma consulta, consulte o plano de execução de consulta no console do Google Cloud :

  1. Acesse a página Instâncias do Spanner no console doGoogle Cloud .

    Acessar a página "Instâncias"

  2. Clique no nome da instância que você quer consultar.

  3. No menu de navegação, selecione o banco de dados que você quer consultar e clique em Spanner Studio.

  4. Insira a consulta a ser testada.

  5. No menu Executar consulta, selecione Somente explicação. O Spanner exibe o plano de consulta.

Procure pelo menos um dos seguintes operadores no plano de consulta:

  • Verificação de tabela
  • Verificação de índice
  • Aplicar cruzada ou distribuição distribuída cruzada

As seções a seguir explicam o significado de cada operador.

Operador de verificação da tabela

O operador verificação de tabela indica que o Spanner não usou um índice secundário:

Operador de verificação de tabela em um plano de consulta.

Por exemplo, suponha que a tabela Albums não tenha índices secundários e você execute a seguinte consulta:

SELECT AlbumTitle FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");

Como não há índices a serem usados, o plano de consulta inclui um operador de verificação de tabela.

Operador de verificação de índice

O operador index scan indica que o Spanner usou um índice secundário ao processar a consulta:

Operador de verificação de índice em um plano de consulta.

Por exemplo, suponha que você adicione um índice à tabela Albums:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Em seguida, execute a seguinte consulta:

SELECT AlbumTitle FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");

O índice AlbumsByAlbumTitle contém AlbumTitle, que é a única coluna que a consulta seleciona. Como resultado, o plano de consulta inclui um operador de verificação de índice.

operador cross apply

Em alguns casos, o Spanner usa um índice que contém apenas algumas das colunas selecionadas pela consulta. Como resultado, o Spanner precisa mesclar o índice com a tabela base.

Quando esse tipo de mesclagem ocorre, o plano de consulta inclui um operador cross apply ou distributed cross apply que tem as seguintes entradas:

  • Um operador de verificação de índice para o índice de uma tabela
  • Um operador de verificação de tabela para a tabela que tem o índice

Aplicação cruzada distribuída em um plano de consulta com uma verificação de índice e uma verificação de tabela como entradas.

Por exemplo, suponha que você adicione um índice à tabela Albums:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Em seguida, execute a seguinte consulta:

SELECT * FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");

O índice AlbumsByAlbumTitle contém AlbumTitle, mas a consulta seleciona todas as colunas na tabela, não apenas AlbumTitle. Como resultado, o plano de consulta inclui um operador de aplicação cruzada distribuída, com uma verificação de índice de AlbumsByAlbumTitle e uma verificação de tabela de Albums como suas entradas.

Escolha outro índice

Depois de encontrar o índice que o Spanner usou para sua consulta, tente executar a consulta com um índice diferente ou verificando a tabela base em vez de usar um índice. Para especificar o índice, adicione uma diretiva FORCE_INDEX à consulta.

Se você encontrar uma versão mais rápida da consulta, atualize seu aplicativo para usar a versão mais rápida.

Diretrizes para escolher um índice

Use estas diretrizes para decidir qual índice testar para a consulta:

  • Se a consulta atender a qualquer um desses critérios, tente usar a tabela base em vez de um índice secundário:

    • A consulta verifica a igualdade com um prefixo da chave primária da tabela base (por exemplo, SELECT * FROM Albums WHERE SingerId = 1).
    • Um grande número de linhas satisfaz os predicados de consulta (por exemplo, SELECT * FROM Albums WHERE AlbumTitle != "There Is No Album With This Title").
    • A consulta usa uma tabela base que contém apenas algumas centenas de linhas.

  • Se a consulta tiver um predicado muito seletivo (por exemplo, REGEXP_CONTAINS, STARTS_WITH, <, <=, >, >= ou !=), tente usar um índice que inclua as mesmas colunas usadas no predicado.

Testar a consulta atualizada

Use o console do Google Cloud para testar a consulta atualizada e descobrir quanto tempo leva para processá-la.

Se sua consulta incluir parâmetros de consulta e um parâmetro de consulta estiver vinculado a alguns valores muito mais frequentemente do que outros, vincule o parâmetro de consulta a um desses valores nos testes. Por exemplo, se a consulta incluir um predicado como WHERE country = @countryId e quase todas as consultas vincular @countryId ao valor US, vincule @countryId a US para seus testes de desempenho. Essa abordagem ajuda você a otimizar para as consultas que são executadas com mais frequência.

Para testar a consulta atualizada no console do Google Cloud , siga estas etapas:

  1. Acesse a página Instâncias do Spanner no console doGoogle Cloud .

    Acessar a página "Instâncias"

  2. Clique no nome da instância que você quer consultar.

  3. No menu de navegação, clique no banco de dados que você quer consultar e, em seguida, clique em Spanner Studio.

  4. Insira a consulta a ser testada, incluindo a diretiva FORCE_INDEX e clique em Executar consulta.

    O console do Google Cloud abre a guia Tabela de resultados e mostra os resultados da consulta, incluindo o tempo que o serviço do Spanner levou para processar a consulta.

    Essa métrica não inclui outras fontes de latência, como o tempo que o console do Google Cloud levou para interpretar e exibir os resultados da consulta.

Limitação de consultas

Durante a execução da consulta, o Spanner pode limitar as consultas em vários lugares.

Tempo de espera do cliente e Atraso na fila do servidor são as duas principais métricas de limitação.

Tempo de espera do cliente

O tempo de espera do cliente representa o tempo que o cliente do Spanner espera que o aplicativo consuma os resultados. Isso indica que o cliente não pode processar os resultados tão rápido quanto o Spanner os produz. Para resolver esse problema, aumente o desempenho do aplicativo de consumo ou armazene em buffer todos os resultados no aplicativo cliente e processe-os após a conclusão da consulta.

Atraso da fila do servidor

O atraso na fila do servidor ocorre quando o servidor de processamento atrasa o agendamento da execução da consulta. No painel Resumo da consulta, verifique a métrica Atraso na fila do servidor. Se a métrica não estiver presente, não houve atraso no servidor.

Esse atraso pode indicar que os servidores que executam a consulta estão sobrecarregados. Para verificar se há um ponto de acesso, consulte Encontrar pontos de acesso no banco de dados. Para resolver problemas de pontos de acesso, consulte Resolver problemas de pontos de acesso usando estatísticas de divisão de pontos de acesso.

Dados alterados recentemente

As mudanças nos dados da tabela podem afetar o desempenho da consulta.

Pacote de estatísticas desatualizado

Se o otimizador usar um pacote de estatísticas desatualizado, ele poderá escolher um plano abaixo do ideal. Na seção Resumo da consulta, é possível verificar o pacote de estatísticas. Se o pacote estiver desatualizado ou ausente, execute ANALYZE para garantir que as estatísticas do otimizador estejam atualizadas.

Pacote de estatísticas no resumo da consulta

Para mais informações, consulte Pacotes de estatísticas.

Mudanças no conteúdo da tabela

O desempenho da consulta depende dos dados que ela processa. A melhor maneira de resolver um problema de desempenho de consulta depende de como os dados mudaram:

  • Distorção na distribuição de valores: o pacote de estatísticas captura essa distorção, mas o otimizador de consultas só pode usar essas informações quando você usa valores literais na consulta.
  • Grande mudança na contagem de linhas: avalie se os predicados filtram as linhas de maneira suficiente à medida que a tabela aumenta de tamanho.
  • Distorção no tamanho do valor: a distorção no tamanho dos valores é problemática em conjunto com predicados escalares caros (por exemplo, realizar um predicado LIKE em um valor STRING que contém strings grandes).

Para receber mais insights sobre a execução de consultas, use a API REST.