Versioni dello strumento di ottimizzazione delle query di Spanner

Questa pagina descrive e fornisce una cronologia delle varie query Spanner delle versioni degli strumenti di ottimizzazione. 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 nuova query delle versioni degli strumenti di ottimizzazione. Per impostazione predefinita, ogni database inizia a utilizzare la versione più recente di almeno 30 giorni dopo il rilascio della versione.

Se utilizzi un database di dialetti GoogleSQL, puoi gestire la versione dell'ottimizzatore delle query utilizzati dalle tue query. Prima di impegnarti per l'ultima versione, puoi confrontare i profili delle prestazioni delle query tra le versioni precedenti e quelle più recenti. A per saperne 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 .

Versione 7: 22 maggio 2024 (più recente)

  • È 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 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 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. 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 principali anche se le statistiche dello strumento di ottimizzazione non sono disponibili o segnalare la tabella di base è piccolo.

  • Introducono il join hash a passaggio singolo, attivato dal nuovo suggerimento 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 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 sul file secondario destro dell'operatore di join 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 nuova modalità (hash_join_execution=one_pass), un join hash verrà trasferito sul disco se il suo input lato build non può essere inserito in memoria ed eseguirà sempre la scansione 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 unione, l'unione di unione, abilitata utilizzando un nuovo METODO DI JOIN il valore del suggerimento per la query.

    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 dell'hash della trasmissione, attivato utilizzando un nuovo Valore del 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'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 aggregato MAX o MIN (o HAVING MAX/MAX) nell'elenco SELECT. Prima di questa modifica, Spanner caricava gli elementi non raggruppati aggiuntivi 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 persino anche se non è richiesto 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 con LIMIT. Dopo questa modifica, l'ottimizzatore applica l'ordinamento con il limite sul lato di input o incrociato.

    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 più calcoli che potrebbero includere una sottoquery o la costruzione di struct mediante 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. Per esempio, la query ha un limite e l'ordinamento dipende da questi calcoli, allora è possibile anche eseguire il push 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 in determinate circostanze.
  • Consente di migliorare le prestazioni di un'analisi in un elemento GROUP BY in determinate situazioni.

Versione 1: 18 giugno 2019

  • Include molte ottimizzazioni basate su regole, come il push-down del predicato, la limitazione push-down, join ridondante e rimozione di espressioni ridondanti, per citarne alcuni.

  • Utilizza le statistiche sui dati degli utenti per selezionare l'indice da usare per accedere a ciascuno .

Passaggi successivi