Versioni dello strumento di ottimizzazione delle query Spanner

Questa pagina descrive e fornisce una cronologia delle varie versioni dell'ottimizzatore delle query Spanner. La versione predefinita attuale è 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 dell'ottimizzatore non prima di 30 giorni dal rilascio della versione.

Puoi gestire la versione dell'ottimizzatore di query utilizzata dalle tue query per i database con dialetto GoogleSQL e PostgreSQL. Prima di eseguire il commit dell'ultima versione, puoi confrontare i profili di rendimento delle query tra le versioni precedenti e l'ultima versione. Per saperne di più, consulta Gestire l'ottimizzatore di query.

Cronologia delle versioni dello strumento di ottimizzazione delle query

Di seguito è riportato un riepilogo degli aggiornamenti apportati all'ottimizzatore di query in ogni release.

Versione 8: 28 ottobre 2024 (predefinita e più recente)

  • WITH vengono prese in considerazione quando si scelgono piani basati sui costi.

  • Miglioramento delle prestazioni delle query di ricerca indicizzate e cross-apply distribuite.

  • Riordino migliorato di JOIN.

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

  • Miglioramento delle prestazioni 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

  • È stato 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 chiave.

  • È stato 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 full outer join.

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

  • È stata attivata l'ottimizzazione basata sui costi per le query DML.

Versione 5: 15 luglio 2022

  • Modello di costi migliorato per la selezione dell'indice, la gestione della distribuzione, il posizionamento dell'ordinamento e la selezione di GROUP BY.

  • È stato aggiunto il supporto per la selezione dell'algoritmo di unione basato sui costi, che sceglie tra hash e applica l'unione. L'unione di tipo Merge richiede comunque l'utilizzo di un suggerimento per la query.

  • È stato aggiunto il supporto per la commutatività del 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 interleaved.
    • Miglioramento della copertura dell'utilizzo dell'indice secondario.
    • Selezione degli indici migliorata quando le statistiche dell'ottimizzatore non sono aggiornate.
    • Preferisci gli indici secondari con predicati sulle colonne indicizzate principali anche se le statistiche dell'ottimizzatore non sono disponibili o segnalano che la tabella di base è piccola.

  • Introduce l'unione hash a una sola passata, attivata dal nuovo suggerimento hash_join_execution.

    Suggerimento per l'iscrizione:

    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 laterale di build dell'hash join è grande. È previsto che l'hash join a una passata abbia prestazioni migliori quando osservi quanto segue nel profilo di esecuzione della query:

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

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

  • Miglioramento della selezione del numero di tasti utilizzati per la ricerca.

Versione 3: 1° agosto 2021

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

    Suggerimento per la dichiarazione:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

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

    Suggerimento per partecipare:

    GoogleSQL 

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

    PostgreSQL 

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

  • Aggiunge un nuovo algoritmo di unione, push broadcast hash join, attivato utilizzando un nuovo valore del suggerimento per la query JOIN METHOD.

    Suggerimento per partecipare:

    GoogleSQL 

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

    PostgreSQL 

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

  • Introduce l'operatore distributed merge union, che è abilitato per impostazione predefinita, se applicabile. Questa operazione migliora le prestazioni delle query.

  • Un piccolo miglioramento delle prestazioni 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 le prestazioni di alcune query con LIMIT quando è presente un operatore cross apply introdotto dai join e la query richiede risultati ordinati con LIMIT. Dopo questa modifica, l'ottimizzatore applica l'ordinamento con il limite sul lato input di 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 più calcoli tramite JOIN.

    Esegue più calcoli, che possono includere una sottoquery o la costruzione di una struttura tramite join. In questo modo, le prestazioni delle query migliorano in diversi modi, ad esempio: È possibile eseguire più calcoli in modo distribuito e anche più operazioni che dipendono dai calcoli push. Ad esempio, se la query ha un limite e l'ordinamento dipende da questi calcoli, il limite può essere applicato anche 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 le prestazioni di una scansione 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 push-down dei limiti, la rimozione di join e espressioni ridondanti e altro ancora.

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

Passaggi successivi