Esta página descreve e fornece 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 nova consulta do otimizador. Por padrão, cada banco de dados começa a usar a versão mais recente do otimizador pelo menos 30 dias após o lançamento da versão.
Se você estiver usando um banco de dados de dialeto GoogleSQL, é possível gerenciar a versão do otimizador de consultas usadas pelas consultas. Antes de confirmar com a versão mais recente, você pode comparar consultar perfis de desempenho entre as versões mais antigas e a mais recente. Para Saiba mais em 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 varredura com base em estatísticas para consultas que não têm predicados pesquisável para todas as partes principais.
Suporte adicionado para a seleção baseada em custo de operações "hash join".
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.
Melhorias na estimativa de cardinalidade e no modelo de custo.
A otimização baseada em custos foi ativada para consultas DML.
Versão 5: 15 de julho de 2022
Modelo de custo aprimorado para seleção de índices, gerenciamento de distribuição e classificação posição e
GROUP BY
seleção.Foi adicionado suporte para seleção de algoritmo de junção baseada em custo que escolhe entre usar hash e aplicar mesclagem. 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 de índices secundários.
- 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 principais colunas indexadas se as estatísticas do otimizador não estiverem disponíveis ou informar a tabela base é pequeno.
Introduz a junção hash de cartão único, 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 função hash join é grande. A junção de hash de uma passagem terá um desempenho melhor quando você observar o seguinte no perfil de execução de consulta:
- O número de execuções no filho direito da junção hash é maior do 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 de se a junção for muito grande para caber na memória, o lado do build será dividido em em vários lotes e podemos 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 cabe na memória e sempre verifica a sondagem lado 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 de 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} */ (...)
Introduz a união Distributed merge (em inglês). , 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á uma operador cross apply apresentado por mesclagens, e a consulta solicita resultados classificados resultados com LIMIT. Após essa alteração, o otimizador aplica a função com o limite no lado "input" do "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, como: É possível fazer mais cálculos de maneira distribuída e mais operações que dependem dos cálculos enviados também podem ser empurrados para baixo. Para exemplo, a consulta tem um limite, e a ordem de classificação depende dessas computações, o limite também pode ser empurrado 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
eLIKE
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
- Para saber mais sobre o otimizador de consultas, consulte Sobre o otimizador de consultas.
- Para gerenciar a versão do otimizador e o pacote de estatísticas do cenário, consulte Gerenciar o otimizador de consultas.