Versões do otimizador de consultas do Spanner

Esta página descreve e fornece um histórico das várias versões do otimizador de consultas do Spanner. A versão predefinida atual é 7. Para saber mais sobre o otimizador de consultas, consulte o artigo Acerca do otimizador de consultas.

O Spanner implementa atualizações do otimizador de consultas como novas versões do otimizador de consultas. Por predefinição, cada base de dados começa a usar a versão mais recente do otimizador, no mínimo, 30 dias após o lançamento dessa versão.

Se estiver a usar uma base de dados com dialeto GoogleSQL, pode gerir a versão do otimizador de consultas que as suas consultas usam. Antes de confirmar a versão mais recente, pode comparar os perfis de desempenho das consultas entre as versões anteriores e a versão mais recente. Para saber mais, consulte o artigo Faça a gestão do otimizador de consultas.

Histórico de versões do otimizador de consultas

Segue-se um resumo das atualizações feitas ao otimizador de consultas em cada versão.

Versão 8: 28 de outubro de 2024 (mais recente)

  • WITH são consideradas quando se fazem escolhas de planos baseadas em custos.

  • Desempenho melhorado das consultas de aplicação cruzada distribuídas e de pesquisa indexada.

  • JOIN Reordenação melhorada.

  • Desempenho melhorado das consultas com cláusulas IN (...) grandes.

  • Melhoria do desempenho do GROUP BY em determinados casos.

  • Outras melhorias, incluindo um processamento mais eficiente de consultas com LIMIT, chaves estrangeiras e seleção de índice.

Versão 7: 22 de maio de 2024 (predefinição)

  • Foi adicionado suporte para a seleção baseada em custos de planos de união de índices.

  • Foi adicionado suporte para a seleção inteligente de planos de procura versus planos de análise com base nas estatísticas de consultas que não têm predicados pesquisáveis para todas as partes principais.

  • Foi adicionado suporte para a seleção baseada em custos de junções de hash.

Versão 6: 11 de setembro de 2023

  • Envio de limites e envio de predicados melhorados através de junções externas completas.

  • Estimativa de cardinalidade e modelo de custo melhorados.

  • Otimização baseada em custos ativada para consultas DML.

Versão 5: 15 de julho de 2022

  • Modelo de custos melhorado para a seleção de índices, a gestão da distribuição, o posicionamento da ordenação e a seleção de GROUP BY.

  • Foi adicionado suporte para a seleção do algoritmo de junção com base no custo, que escolhe entre a junção de hash e a junção de aplicação. A junção de união continua a exigir a utilização de uma sugestão de consulta.

  • Foi adicionado suporte para a comutatividade da junção baseada em custos.

Versão 4: 1 de março de 2022

  • Melhorias na seleção de índices secundários.

    • Utilização melhorada do índice secundário numa junção entre tabelas intercaladas.
    • Cobertura melhorada da utilização do índice secundário.
    • Seleção de índice melhorada quando as estatísticas do otimizador estão desatualizadas.
    • Prefira índices secundários com predicados em colunas indexadas principais, mesmo que as estatísticas do otimizador não estejam disponíveis ou indiquem que a tabela base é pequena.

  • Apresenta a junção de hash de passagem única, ativada pela nova sugestão hash_join_execution.

    Sugestão de participação:

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=hash_join, hash_join_execution=one_pass} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=hash_join, hash_join_execution=one_pass */ (...)

    O novo modo é vantajoso quando a entrada lateral de criação da junção hash é grande. Espera-se que a junção hash de uma passagem tenha um melhor desempenho quando observar o seguinte no perfil de execução da consulta:

    • O número de execuções no filho direito da junção de hash é superior ao número de execuções no operador de junção de hash.
    • A latência no elemento secundário direito do operador de junção hash também é elevada.

    Por predefinição (hash_join_execution=multi_pass), se a entrada do lado de criação da junção hash for demasiado grande para caber na memória, o lado de criação é dividido em vários lotes e podemos analisar o lado de sondagem várias vezes. Com o novo modo (hash_join_execution=one_pass), uma junção hash é derramada para o disco se a entrada do lado de compilação não couber na memória e analisa sempre o lado de sondagem apenas uma vez.

  • Uma melhoria na seleção do número de teclas usadas para a procura.

Versão 3: 1 de agosto de 2021

  • Adiciona um novo algoritmo de junção, a junção de união, ativado através de um novo valor de sugestão de consulta JOIN METHOD.

    Sugestão de extrato:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

    /*@ join_method=merge_join */
SELECT ...

    Sugestão para participar:

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=merge_join} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=merge_join */ (...)

  • Adiciona um novo algoritmo de junção, a junção de hash de transmissão push, ativado através de um novo valor da sugestão de consulta JOIN METHOD.

    Sugestão para participar:

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=push_broadcast_hash_join} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=push_broadcast_hash_join} */ (...)

  • Apresenta o operador distributed merge union, que está ativado por predefinição quando aplicável. Esta operação melhora o desempenho das consultas.

  • Uma pequena melhoria no desempenho de uma análise sob uma GROUP BY quando não existe um agregado MAX ou MIN (ou HAVING MAX/MAX) na lista SELECT. Antes desta alteração, o Spanner carregava a coluna adicional não agrupada, mesmo que não fosse necessária para a consulta.

    Por exemplo, considere a seguinte tabela:

    GoogleSQL 

    CREATE TABLE myTable(
  a INT64,
  b INT64,
  c INT64,
  d INT64)
PRIMARY KEY (a, b, c);

    PostgreSQL 

    CREATE TABLE myTable(
  a bigint,
  b bigint,
  c bigint,
  d bigint,
  PRIMARY KEY(a, b, c)
);

    Antes desta alteração, a seguinte consulta teria carregado a coluna c, mesmo que não fosse necessária para a consulta.

    SELECT a, b
FROM myTable
GROUP BY a, b

  • Melhora o desempenho de algumas consultas com LIMIT quando existe um operador de aplicação cruzada introduzido por junções e a consulta pede resultados ordenados com LIMIT. Após esta alteração, o otimizador aplica a ordenação com o limite no lado da entrada da aplicação cruzada primeiro.

    Exemplo:

    GoogleSQL 

    SELECT a2.*
FROM Albums@{FORCE_INDEX=_BASE_TABLE} a1
JOIN Albums@{FORCE_INDEX=_BASE_TABLE} a2 USING(SingerId)
ORDER BY a1.AlbumId
LIMIT 2;

    PostgreSQL 

    SELECT a2.*
FROM albums/*@ force_index=_base_table */ a1
JOIN albums/*@ force_index=_base_table */ a2 USING(singerid)
ORDER BY a1.albumid
LIMIT 2;

  • Melhora o desempenho das consultas ao enviar mais cálculos através do JOIN.

    Envia mais cálculos que podem incluir uma subconsulta ou uma construção de struct através da junção. Isto melhora o desempenho das consultas de várias formas, como: É possível fazer mais cálculos de forma distribuída e também é possível enviar mais operações que dependem dos cálculos enviados. Por exemplo, se a consulta tiver um limite e a ordem de ordenação depender desses cálculos, o limite também pode ser enviado através da junção.

    Exemplo:

    SELECT
  t.ConcertDate,
  (
    SELECT COUNT(*) FROM UNNEST(t.TicketPrices) p WHERE p > 10
  ) AS expensive_tickets,
  u.VenueName
FROM Concerts t
JOIN Venues u ON t.VenueId = u.VenueId
ORDER BY expensive_tickets
LIMIT 2;

Versão 2: 1 de março de 2020

  • Adiciona otimizações na seleção de índices.
  • Melhora o desempenho dos predicados REGEXP_CONTAINS e LIKE em determinadas circunstâncias.
  • Melhora o desempenho de uma análise sob um GROUP BY em determinadas situações.

Versão 1: 18 de junho de 2019

  • Inclui muitas otimizações baseadas em regras, como o envio de predicados, o envio de limites, a remoção de junções redundantes e de expressões redundantes, entre outras.

  • Usa estatísticas sobre os dados do utilizador para selecionar o índice a usar para aceder a cada tabela.

O que se segue?