Versões do otimizador de consultas do Spanner

Nesta página, descrevemos e fornecemos um histórico das várias versões do otimizador de consultas do Spanner. A versão padrão atual é 6. Consulte Sobre o otimizador de consultas para saber mais.

O Spanner implanta atualizações do otimizador de consultas como novas versões do otimizador de consultas. Por padrão, cada banco de dados começa a usar a versão mais recente do otimizador menos de 30 dias após o lançamento dessa versão.

Se você estiver usando um banco de dados do dialeto GoogleSQL, é possível gerenciar a versão do otimizador que suas consultas usam. Antes de confirmar para a versão mais recente, compare os perfis de desempenho da consulta entre as versões mais antigas e a mais recente. Para saber mais, consulte Gerenciar o otimizador de consultas.

Histórico de versões do otimizador de consultas

Veja a seguir um resumo das atualizações feitas no otimizador de consultas em cada versão.

Versão 6: 11 de setembro de 2023 (mais recente e padrão)

• Melhoria no limite de envio e envio de predicados por meio de junções externas completas.

• Aprimoramento da estimativa de cardinalidade e do modelo de custo.

• Ativação da otimização baseada em custo nas consultas DML.

Versão 5: 15 de julho de 2022

• Modelo de custo aprimorado para seleção de índices, gerenciamento de distribuição, posicionamento de classificação e seleção de GROUP BY.

• Adicionado suporte à seleção de algoritmo de mesclagem com base em custo que escolhe entre hash e apply join. A mesclagem de mesclagem ainda exige o uso de uma dica de consulta.

• Adicionado suporte à comutatividade de mesclagens com base em custo.

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

• Melhorias na seleção de índice secundário.

  • Melhoria no uso do índice secundário em uma mesclagem entre tabelas intercaladas.
  • Melhoria na cobertura do uso do índice secundário.
  • Seleção de índice aprimorada 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 informe que a tabela base for pequena.

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

  Dica de mesclagem:

  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 é útil quando a entrada do lado do build da mesclagem de hash é grande. Espera-se que uma junção de hash de cartão tenha um desempenho melhor quando você observa o seguinte no perfil de execução de consulta:

  • O número de execuções no filho direito da mesclagem de hash é maior que o número de execuções no operador de mesclagem de hash.
  • A latência no filho direito do operador "hash join" também é alta.

  Por padrão (hash_join_execution=multi_pass), se a entrada do lado do build do hash join for muito grande para caber na memória, o lado do build será dividido em vários lotes, e o lado da sondagem poderá ser verificado várias vezes. Com o novo modo (hash_join_execution=one_pass), uma mesclagem de hash será transmitida para o disco se a entrada secundária do build não couber na memória e sempre verificará o lado da sondagem apenas uma vez.

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

Versão 3: 1o de agosto de 2021

• Adiciona um novo algoritmo de mesclagem, merge join, ativado usando um novo valor de dica de consulta JOIN METHOD.

  Dica de instrução:

  GoogleSQL

  @{join_method=merge_join}
  SELECT ...
  

  PostgreSQL

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

  Dica de participação:

  GoogleSQL

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

  PostgreSQL

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

• Adiciona um novo algoritmo de mesclagem, push broadcast hash join, ativado usando um novo valor de dica de consulta JOIN METHOD.

  Dica de participação:

  GoogleSQL

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

  PostgreSQL

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

• Apresenta o operador Distribute merge union, que é ativado por padrão quando aplicável. Essa operação melhora o desempenho das consultas.

• Uma pequena melhoria no desempenho de uma verificação em um GROUP BY quando não há agregação MAX ou MIN (ou HAVING MAX/MAX) na lista SELECT. Antes dessa mudança, o Spanner carregava a coluna extra não agrupada, mesmo que ela não fosse exigida pela 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 dessa alteração, a consulta a seguir carregava a coluna c, embora não seja exigida pela consulta.

  SELECT a, b
  FROM myTable
  GROUP BY a, b
  

• Melhora o desempenho de algumas consultas com LIMIT quando há um operador de aplicação cruzada introduzido por mesclagens e a consulta solicita resultados classificados com LIMIT. Após essa mudança, o otimizador aplica a classificação com o limite no lado "input" de cross apply 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 da consulta enviando mais cálculos pelo JOIN.

  Envia mais cálculos que podem incluir uma subconsulta ou construção de estrutura por meio da mesclagem. Isso melhora o desempenho da consulta de algumas maneiras. Por exemplo: Mais cálculos podem ser feitos de maneira distribuída e mais operações que dependem dos cálculos enviados também podem ser reduzidas. Por exemplo, se a consulta tem um limite e a ordem de classificação depende desses cálculos, o limite também pode ser enviado por meio 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: 1o de março de 2020

• Adiciona otimizações na seleção do índice.
• Melhora o desempenho dos predicados REGEXP_CONTAINS e LIKE em determinadas circunstâncias.
• Aprimora o desempenho de uma verificação em um GROUP BY em determinadas situações.

Versão 1: 18 de junho de 2019

• Inclui muitas otimizações baseadas em regras, como pushdown de predicado, pushdown de limite, junção redundante e remoção de expressão redundante, para citar alguns.

• Usa estatísticas em dados do usuário para selecionar qual índice usar para acessar cada tabela.

A seguir

• Consulte Sobre o otimizador de consultas para saber mais.
• Para gerenciar a versão do otimizador e o pacote de estatísticas de acordo com seu cenário, consulte Gerenciar o otimizador de consultas.