Versioni dello strumento di ottimizzazione delle query di Spanner

Questa pagina descrive e fornisce una cronologia delle varie versioni dell'ottimizzatore delle query di Spanner. La versione predefinita attuale è la 6. Per scoprire di più su questo strumento, consulta Informazioni sullo strumento di ottimizzazione delle query.

Spanner implementa gli aggiornamenti dello strumento di ottimizzazione delle query come nuove versioni. Per impostazione predefinita, ogni database inizia a utilizzare la versione più recente dell'ottimizzatore almeno 30 giorni dopo il rilascio della versione.

Se utilizzi un database di dialetti GoogleSQL, puoi gestire la versione dell'ottimizzazione delle query utilizzata dalle query. Prima di impegnarti per l'ultima versione, puoi confrontare i profili delle prestazioni delle query tra le versioni precedenti e l'ultima versione. Per scoprire di più, consulta Gestire lo strumento di ottimizzazione delle query.

Cronologia delle versioni dello strumento di ottimizzazione delle query

Di seguito è riportato un riepilogo degli aggiornamenti apportati allo strumento di ottimizzazione delle query in ogni release.

Versione 7: 22 maggio 2024 (più recente)

  • È stato aggiunto il supporto per la selezione dei piani Index Union in base ai costi.

  • È stato aggiunto il supporto per la selezione intelligente di piani di ricerca e scansione basati sulle statistiche per le query che non hanno predicati ricercabili per tutte le parti chiave.

  • È stato aggiunto il supporto per la selezione dei join hash basata sui costi.

Versione 6: 11 settembre 2023 (predefinita)

  • Push dei limiti e push dei predicati migliorati attraverso i join outer completi.

  • Stima della cardinalità e modello di costo migliorati.

  • Abilitata l'ottimizzazione basata sui costi per le query DML.

Versione 5: 15 luglio 2022

  • Modello di costo migliorato per la selezione degli indici, la gestione della distribuzione, il posizionamento di ordinamento e la selezione di GROUP BY.

  • Aggiunto il supporto per la selezione dell'algoritmo di join in base ai costi che sceglie tra hash e apply join. Il join di unione richiede comunque l'utilizzo di un suggerimento per le query.

  • Aggiunto il supporto per la commutatività dei join basata sui costi.

Versione 4: 1° marzo 2022

  • Miglioramenti alla selezione dell'indice secondario.

    • Miglioramento dell'utilizzo dell'indice secondario in un join tra tabelle con interleaving.
    • Copertura dell'utilizzo dell'indice secondario migliorata.
    • Selezione dell'indice migliorata quando le statistiche dell'ottimizzatore non sono aggiornate.
    • Preferisci gli indici secondari con predicati sulle colonne indicizzate leader anche se le statistiche dell'ottimizzatore non sono disponibili o se segnali che la tabella di base è piccola.

  • Introduce l'hashing a passaggio singolo, attivato dal nuovo hint hash_join_execution.

    Suggerimento di partecipazione:

    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 */ (...)

    La nuova modalità è utile quando l'input del lato della build dell'hash join è grande. Un join hash con passaggio dovrebbe avere prestazioni migliori se osserva quanto segue nel profilo di esecuzione della query:

    • Il numero di esecuzioni nell'elemento figlio destro del join hash è maggiore del numero di esecuzioni sull'operatore di join hash.
    • Anche la latenza sul file secondario destro dell'operatore di join hash è elevata.

    Per impostazione predefinita (hash_join_execution=multi_pass), se l'input del lato build del join hash è troppo grande per essere contenuto nella memoria, il lato build viene suddiviso in più batch e potremmo analizzare il lato del probe più volte. Con la nuova modalità (hash_join_execution=one_pass), un join hash viene trasferito sul disco se l'input lato build non può essere inserito nella memoria ed eseguirà sempre la scansione del lato del probe solo una volta.

  • Un miglioramento nella selezione del numero di chiavi utilizzate per la ricerca.

Versione 3: 1° agosto 2021

  • Aggiunge un nuovo algoritmo di join, join di unione, abilitato utilizzando un nuovo valore di suggerimento per la query JOIN METHOD.

    Suggerimento istruzione:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

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

    Suggerimento di unione:

    GoogleSQL 

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

    PostgreSQL 

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

  • Aggiunge un nuovo algoritmo di join, push join hash join, abilitato utilizzando un nuovo valore di suggerimento per la query JOIN METHOD.

    Suggerimento di unione:

    GoogleSQL 

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

    PostgreSQL 

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

  • Introduce l'operatore unione di unione distribuita, che è abilitato per impostazione predefinita, se applicabile. Questa operazione migliora le prestazioni delle query.

  • Un piccolo miglioramento alle prestazioni di una scansione in un GROUP BY quando non è presente un aggregato MAX o MIN (o HAVING MAX/MAX) nell'elenco SELECT. Prima di questa modifica, Spanner caricava la colonna non raggruppata aggiuntiva anche se non era richiesta dalla query.

    Ad esempio, considera la seguente tabella:

    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)
);

    Prima di questa modifica, la seguente query avrebbe caricato la colonna c anche se non era richiesta dalla query.

    SELECT a, b
FROM myTable
GROUP BY a, b

  • Migliora le prestazioni di alcune query con LIMIT quando è presente un operatore di applicazione incrociata introdotto dai join e la query richiede risultati ordinati con LIMIT. Dopo la modifica, l'ottimizzatore applica prima l'ordinamento con il limite sul lato di input o "Cross apply".

    Esempio:

    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;

  • Migliora le prestazioni delle query eseguendo il push di più calcoli tramite JOIN.

    Esegue il push di più calcoli che potrebbero includere una sottoquery o la creazione di struct mediante join. Ciò migliora le prestazioni delle query in alcuni modi, ad esempio: è possibile eseguire più calcoli in modo distribuito ed è possibile eseguire anche il push-down di più operazioni che dipendono dai calcoli eseguiti. Ad esempio, la query ha un limite e l'ordinamento dipende da questi calcoli, quindi anche il limite può essere eseguito tramite join.

    Esempio:

    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;

Versione 2: 1° marzo 2020

  • Aggiunge ottimizzazioni nella selezione dell'indice.
  • Migliora le prestazioni dei predicati REGEXP_CONTAINS e LIKE in determinate circostanze.
  • Migliora le prestazioni di un'analisi in un GROUP BY in determinate situazioni.

Versione 1: 18 giugno 2019

  • Include molte ottimizzazioni basate su regole come il push-down dei predicati, il pushdown limitato, il join ridondante e la rimozione di espressioni ridondanti, per citarne alcune.

  • Utilizza le statistiche sui dati utente per selezionare l'indice da utilizzare per accedere a ogni tabella.

Passaggi successivi