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 è 6. 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 nuova query delle versioni degli strumenti di ottimizzazione. 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 di dialetti GoogleSQL, puoi gestire la versione dell'ottimizzatore delle query utilizzati 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 approfondire, 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 7: 22 maggio 2024 (ultima)

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

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

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

Versione 6: 11 settembre 2023 (predefinita)

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

  • Stima della cardinalità e modello di costo migliorati.

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

Versione 5: 15 luglio 2022

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

  • Aggiunto il supporto per la selezione dell'algoritmo di join in base ai costi che consente di scegliere tra e applica il join. L'unione per accodamento richiede ancora l'utilizzo di un suggerimento di query.

  • Aggiunto il supporto per la commutatività dei join basata 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.
    • 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 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 del lato della build dell'hash join è grande. Un join hash con passaggio dovrebbe avere prestazioni migliori quando osserva quanto segue nel profilo di esecuzione della query:

    • Il numero di esecuzioni nell'elemento figlio destro del join hash è maggiore rispetto al numero di esecuzioni sull'operatore di join 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 l'hash join è troppo grande per essere contenuto in memoria, il lato build è suddiviso in più batch e potremmo scansionare il lato del probe più volte. Con la nuova modalità (hash_join_execution=one_pass), un join di hash viene trasferito sul disco se l'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 unione, l'unione di unione, abilitata utilizzando un nuovo METODO DI JOIN il valore del suggerimento per la query.

    Suggerimento per l'istruzione:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

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

    Suggerimento di partecipazione:

    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 di partecipazione:

    GoogleSQL 

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

    PostgreSQL 

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

  • Introduce l'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 base a un valore GROUP BY quando non esiste un valore MAX o MIN aggregato (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 strutture tramite join. Ciò migliora le prestazioni delle query in alcuni modi, ad esempio: È possibile eseguire più calcoli in modo distribuito e più operazioni che dipendono dai calcoli eseguiti tramite push. 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