Versioni dello strumento di ottimizzazione delle query Spanner

Questa pagina descrive e fornisce una cronologia delle varie versioni dello strumento di ottimizzazione delle query di Spanner. La versione predefinita attuale è la 8. Per scoprire di più sullo strumento di ottimizzazione delle query, consulta la panoramica dello strumento di ottimizzazione delle query.

Spanner implementa gli aggiornamenti dello strumento di ottimizzazione delle query come nuove versioni dello strumento di ottimizzazione delle query. Per impostazione predefinita, ogni database inizia a utilizzare l'ultima versione dello strumento di ottimizzazione non prima di 30 giorni dopo il rilascio della versione.

Puoi gestire la versione dello strumento di ottimizzazione delle query utilizzata dalle query per i database di dialetti GoogleSQL e PostgreSQL. Prima di eseguire il commit all'ultima versione, puoi confrontare i profili di rendimento 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 9: 21 luglio 2026 (ultima)

  • Migliora l'efficienza dei join di applicazione distribuita (DA) inviando solo le colonne richieste dall'input al lato della mappa del join.

  • Seleziona automaticamente gli indici sulle colonne calcolate, quando la stessa espressione calcolata è una condizione di filtro o join in una query.

    Ad esempio, consente la selezione dell'indice su Singers((LOWER(FirstName))) se presente per la seguente query:

    GoogleSQL 

    SELECT s.SingerId, s.FirstName, s.LastName
FROM Singers s
WHERE LOWER(s.FirstName) > 'k'
LIMIT 10;

    PostgreSQL 

    SELECT s.singerid, s.firstname, s.lastname
FROM singers s
WHERE LOWER(s.firstname) > 'k'
LIMIT 10;

  • Migliora il rendimento della ricerca degli indici interleaved raggruppando e ordinando le chiavi per ricerche sequenziali efficienti nello spazio di archiviazione.

  • Miglioramenti secondari alla stima della cardinalità.

  • Preferisce euristicamente i piani con applicazione distribuita rispetto all'applicazione con unione distribuita sul lato della mappa se non è presente alcun LIMIT sopra l'applicazione.

  • Sceglie i piani di unione degli indici in modo più aggressivo.

  • Migliora il rendimento di GROUP BY espandendo l'aggregazione basata sulla scansione per supportare i predicati di filtro in cui la chiave di aggregazione viene confrontata con le funzioni che coinvolgono costanti e parametri.

  • Consente l'ottimizzazione del piano basata sui costi per le query che coinvolgono tabelle con schemi denominati.

Versione 8: 28 ottobre 2024 (predefinita)

  • Le clausole WITH vengono prese in considerazione quando si effettuano scelte di piano basate sui costi.

  • Miglioramento del rendimento delle query di ricerca indicizzate e di applicazione incrociata distribuita.

  • Miglioramento del riordinamento di JOIN.

  • Miglioramento del rendimento delle query con clausole IN (...) di grandi dimensioni.

  • Miglioramento del rendimento di GROUP BY in alcuni casi.

  • Altri miglioramenti, tra cui una gestione più efficiente delle query con LIMIT, chiavi esterne e selezione degli indici.

Versione 7: 22 maggio 2024

  • Aggiunto il supporto per la selezione basata sui costi dei piani di unione degli indici.

  • Aggiunto il supporto per la selezione intelligente dei piani di ricerca rispetto a quelli di scansione in base alle statistiche per le query che non hanno predicati ricercabili per tutte le parti della chiave.

  • Aggiunto il supporto per la selezione basata sui costi dei join hash.

Versione 6: 11 settembre 2023

  • Miglioramento del push dei limiti e dei predicati tramite i join esterni completi.

  • Miglioramento della stima della cardinalità e del modello di costo.

  • Ottimizzazione basata sui costi abilitata per le query DML.

Versione 5: 15 luglio 2022

  • Miglioramento del modello di costo per la selezione degli indici, la gestione della distribuzione, il posizionamento dell'ordinamento e la selezione di GROUP BY.

  • Aggiunto il supporto per la selezione dell'algoritmo di join basata sui costi che sceglie tra hash e join di applicazione. Il join di unione richiede ancora l'utilizzo di un suggerimento per la query.

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

Versione 4: 1° marzo 2022

  • Miglioramenti alla selezione degli indici secondari.

    • Miglioramento dell'utilizzo degli indici secondari in un join tra tabelle interleaved.
    • Miglioramento dell'utilizzo degli indici secondari di copertura.
    • Miglioramento della selezione degli indici quando le statistiche dello strumento di ottimizzazione non sono aggiornate.
    • Preferisci gli indici secondari con predicati sulle colonne indicizzate principali anche se le statistiche dello strumento di ottimizzazione non sono disponibili o indicano che la tabella di base è piccola.

  • Introduce il join hash a passaggio singolo, abilitato dal nuovo suggerimento hash_join_execution.

    Suggerimento per il join:

    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 di compilazione del join hash è di grandi dimensioni. È previsto un rendimento migliore del join hash a passaggio singolo quando si osservano i seguenti elementi nel profilo di esecuzione della query:

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

    Per impostazione predefinita (hash_join_execution=multi_pass), se l'input del lato di compilazione del join hash è troppo grande per essere contenuto in memoria, il lato di compilazione viene suddiviso in più batch e potremmo eseguire la scansione del lato di probing più volte. Con la nuova modalità (hash_join_execution=one_pass), un join hash verrà trasferito su disco se l'input del lato di compilazione non può essere contenuto in memoria ed eseguirà sempre la scansione del lato di probing una sola volta.

  • Miglioramento della selezione del numero di chiavi utilizzate per la ricerca.

Versione 3: 1° agosto 2021

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

    Suggerimento per l'istruzione:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

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

    Suggerimento per il join:

    GoogleSQL 

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

    PostgreSQL 

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

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

    Suggerimento per il join:

    GoogleSQL 

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

    PostgreSQL 

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

  • Introduce l'operatore di unione di unione distribuita, che è abilitato per impostazione predefinita quando applicabile. Questa operazione migliora il rendimento delle query.

  • Un piccolo miglioramento del rendimento di una scansione in GROUP BY quando non è presente alcun aggregato MAX o MIN (o HAVING MAX/MAX) nell'elenco SELECT. Prima di questa modifica, Spanner caricava la colonna aggiuntiva non raggruppata 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 è richiesta dalla query.

    SELECT a, b
FROM myTable
GROUP BY a, b

  • Migliora il rendimento di alcune query con LIMIT quando è presente un operatore di applicazione incrociata introdotto dai join e la query richiede risultati ordinati con LIMIT. Dopo questa modifica, lo strumento di ottimizzazione applica prima l'ordinamento con il limite sul lato di input dell'applicazione incrociata.

    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 il rendimento delle query eseguendo più calcoli tramite JOIN.

    Esegue più calcoli, che possono includere una sottoquery o una costruzione di struct tramite join. In questo modo il rendimento delle query migliora in diversi modi, ad esempio: è possibile eseguire più calcoli in modo distribuito e anche altre operazioni che dipendono dai calcoli push possono essere eseguite in push-down. Ad esempio, se la query ha un limite e l'ordinamento dipende da questi calcoli, anche il limite può essere eseguito in push-down 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 degli indici.
  • Migliora il rendimento dei predicati REGEXP_CONTAINS e LIKE in determinate circostanze.
  • Migliora il rendimento di una scansione in GROUP BY in determinate situazioni.

Versione 1: 18 giugno 2019

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

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

Passaggi successivi