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. Para saber mais sobre o otimizador de consultas, consulte Sobre o otimizador de consultas.

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

Se você estiver usando um banco de dados de dialeto GoogleSQL, poderá gerenciar a versão do otimizador de consultas usada pelas consultas. Antes de confirmar com a versão mais recente, compare os perfis de desempenho de consulta entre as versões mais antigas e a mais recente. Para saber mais, confira 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 7: 22 de maio de 2024 (mais recente)

  • Inclusão de suporte para a seleção baseada em custo de planos de união de índices.

  • Foi adicionado suporte à seleção inteligente de planos de busca versus verificação com base em estatísticas para consultas que não têm predicados pesquisável para todas as partes principais.

  • Foi adicionado suporte à seleção de junções de hash baseada em custo.

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

  • O limite empurrado e o predicado empurrando através das junções externas completas foram aprimorados.

  • Melhoria na estimativa de cardinalidade e no modelo de custo.

  • Ativou a otimização com base em custo para consultas DML.

Versão 5: 15 de julho de 2022

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

  • Foi adicionado suporte à seleção do algoritmo de mesclagem com base em custo que escolhe entre a mesclagem de hash e aplicação. A mesclagem ainda exige o uso de uma dica de consulta.

  • Foi adicionado suporte à comutatividade de junção com base em custo.

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

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

    • Melhoria no uso do índice secundário em uma junção entre tabelas intercaladas.
    • Melhoria na cobertura do uso de índice secundário.
    • Seleção de índice aprimorada quando as estatísticas do otimizador estão desatualizadas.
    • Dê preferência a índices secundários com predicados nas colunas indexadas principais, mesmo que as estatísticas do otimizador não estejam disponíveis ou relatem que a tabela base é pequena.
  • Introduçã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 secundária do build da junção de hash é grande. Espera-se que uma junção de hash de transmissão tenha melhor desempenho quando você observar o seguinte no perfil de execução da consulta:

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

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

  • Uma melhoria na seleção de quantas teclas são usadas para 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 da instrução:

    GoogleSQL

    @{join_method=merge_join}
    SELECT ...
    

    PostgreSQL

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

    Dica de mesclagem:

    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 mesclagem:

    GoogleSQL

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

    PostgreSQL

    SELECT ...
    FROM (...)
    JOIN/*@ join_method=push_broadcast_hash_join} */ (...)
    
  • Apresenta o operador distribution 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 da entrada 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: é possível fazer mais cálculos de maneira distribuída e mais operações que dependem dos cálculos enviados também podem ser enviadas para baixo. Por exemplo, se a consulta tiver um limite e a ordem de classificação depender desses cálculos, o limite também poderá ser expandido por 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 sobre dados do usuário para selecionar qual índice usar para acessar cada tabela.

A seguir