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 corrente è 7. Per scoprire di più sullo Strumento di ottimizzazione delle query, consulta Informazioni sullo Strumento di ottimizzazione delle query.

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

Se utilizzi un database in dialetto GoogleSQL, puoi gestire la versione dell'ottimizzatore delle query impiegata dalle tue query. Prima di eseguire l'commit alla versione più recente, puoi confrontare i profili di rendimento delle query tra le versioni precedenti e la versione più recente. 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 all'ottimizzatore delle query in ogni release.

Versione 8: 28 ottobre 2024 (ultima)

  • Le clausole WITH vengono prese in considerazione quando si scelgono i piani in base al costo.

  • Miglioramento delle prestazioni delle query di ricerca indicizzata e di applicazione incrociata distribuite.

  • Riordinamento JOIN migliorato.

  • 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, le chiavi esterne e la selezione degli indici.

Versione 7: 22 maggio 2024 (valore predefinito)

  • È stato aggiunto il supporto per la selezione in base al costo dei piani di unione di indici.

  • È stato 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 dispongono di predicati cercabili per tutte le parti chiave.

  • È stato aggiunto il supporto per la selezione basata sui costi delle unioni con hash.

Versione 6: 11 settembre 2023

  • Miglioramento dell'applicazione di limiti e della definizione di predicati tramite unioni esterne complete.

  • Modello di costo e stima della cardinalità migliorati.

  • È stata attivata l'ottimizzazione in base al costo per le query DML.

Versione 5: 15 luglio 2022

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

  • È stato aggiunto il supporto per la selezione dell'algoritmo di join basato sul costo che sceglie tra join con hash e join con applicazione. L'unione per accodamento richiede ancora l'utilizzo di un suggerimento di query.

  • È stato aggiunto il supporto della commutatività delle unioni basate sui costi.

Versione 4: 1° marzo 2022

  • Miglioramenti alla selezione dell'indice secondario.

    • È stato migliorato l'utilizzo dell'indice secondario in un join tra tabelle interlacciate.
    • È stato migliorato l'utilizzo dell'indice secondario di copertura.
    • Miglioramento della selezione dell'indice quando le statistiche dello strumento di ottimizzazione sono obsolete.
    • Preferisci gli indici secondari con predicati sulle colonne principali indicizzate anche se le statistiche dell'ottimizzatore non sono disponibili o se la tabella di base è piccola.

  • Viene introdotta l'unione con hash a passaggio singolo, abilitata dal nuovo suggerimentohash_join_execution.

    Suggerimento per partecipare:

    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 lato compilazione dell'unione con hash è di grandi dimensioni. Il join hash con una sola passata dovrebbe avere prestazioni migliori se nel profilo di esecuzione delle query osservi quanto segue:

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

    Per impostazione predefinita (hash_join_execution=multi_pass), se l'input lato build della join di hash è troppo grande per essere inserito in memoria, il lato build viene suddiviso in più batch e potremmo eseguire la scansione del lato probe più volte. Con la nuova modalità (hash_join_execution=one_pass), un join di hashing viene trasferito sul disco se il relativo input lato build non può essere memorizzato in memoria e la scansione del lato probe viene sempre eseguita una sola volta.

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

Versione 3: 1° agosto 2021

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

    Suggerimento per l'istruzione:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

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

    Suggerimento per l'unione:

    GoogleSQL 

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

    PostgreSQL 

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

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

    Suggerimento per l'unione:

    GoogleSQL 

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

    PostgreSQL 

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

  • Viene introdotto l'operatore unione per unione distribuita, che è attivato per impostazione predefinita, se applicabile. Questa operazione migliora le prestazioni delle query.

  • Un piccolo miglioramento del rendimento di una scansione in un GROUP BY quando non è presente un valore 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 di applicazione incrociata introdotto dalle unioni e la query richiede risultati ordinati con LIMIT. Dopo questa modifica, l'ottimizzatore 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 le prestazioni delle query inviando più calcoli tramite JOIN.

    Esegue più calcoli che possono includere una sottoquery o la costruzione di una struttura tramite join. Ciò migliora le prestazioni delle query in diversi modi, ad esempio: È possibile eseguire più calcoli in modo distribuito e anche altre operazioni che dipendono dai calcoli inviati possono essere spostate verso il basso. Ad esempio, se la query ha un limite e l'ordinamento dipende da questi calcoli, il limite può essere applicato anche tramite l'unione.

    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 sotto un GROUP BY in determinate situazioni.

Versione 1: 18 giugno 2019

  • Include molte ottimizzazioni basate su regole, ad esempio pushdown dei predicati, pushdown del limite, join ridondanti e rimozione di espressioni ridondanti, per citarne alcuni.

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

Passaggi successivi