Versioni dello strumento di ottimizzazione delle query di Spanner

Questa pagina descrive e fornisce una cronologia delle varie versioni di Strumento di ottimizzazione delle query di Spanner. L'attuale versione predefinita è 6. Per saperne 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 dopo il rilascio della versione.

Se usi un database di dialetti GoogleSQL, puoi gestire la versione dello strumento di ottimizzazione delle query utilizzata dalle query. Prima di eseguire il commit alla versione più recente, puoi confrontare i profili di prestazioni 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 allo strumento di ottimizzazione delle query in ogni release.

Versione 6: 11 settembre 2023 (più recente e predefinita)

  • Miglioramento del pushing dei limiti e del push dei predicati attraverso join outer completi.

  • Stima della cardinalità e modello di costo migliorati.

  • Abilitazione dell'ottimizzazione basata sui costi per le query DML.

Versione 5: 15 luglio 2022

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

  • Aggiunto il supporto per la selezione dell'algoritmo di join basato sui costi, che consente di scegliere tra hashing e apply join. L'unione mediante unione richiede ancora l'utilizzo di un suggerimento per la 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 degli indici secondari in un join tra tabelle con interleaving.
    • Miglioramento della copertura dell'utilizzo degli indici secondari.
    • Selezione dell'indice migliorata quando le statistiche dello strumento di ottimizzazione sono obsolete.
    • Preferisci indici secondari con predicati nelle colonne indicizzate principali anche se le statistiche di ottimizzazione non sono disponibili o se la tabella di base è di dimensioni ridotte.

  • Introduci l'hashing a passaggio singolo, abilitato dal nuovo suggerimento hash_join_execution.

    Suggerimento per unire le persone:

    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à è vantaggiosa quando l'input lato build del join hash è di grandi dimensioni. Si prevede che un passaggio hash join abbia prestazioni migliori se osservi quanto segue nel profilo di esecuzione della query:

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

    Per impostazione predefinita (hash_join_execution=multi_pass), se l'input lato build del join hash è troppo grande per essere inserito in memoria, il lato build viene suddiviso in più batch e potremmo analizzare il lato probe più volte. Con la nuova modalità (hash_join_execution=one_pass), un hash join si estenderà su disco se l'input lato build non è sufficiente in memoria ed eseguirà sempre la scansione del lato del probe una sola volta.

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

Versione 3: 1° agosto 2021

  • Aggiunge un nuovo algoritmo di join, unendo join, abilitato utilizzando un nuovo valore di suggerimento per la query JOIN Method.

    Suggerimento sull'istruzione:

    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 join, push join hash della trasmissione, abilitato utilizzando un nuovo valore di suggerimento di 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} */ (...)

  • Presenta l'operatore unione di unione distribuita, che è abilitato per impostazione predefinita quando applicabile. Questa operazione migliora le prestazioni delle query.

  • Un piccolo miglioramento delle prestazioni di un'analisi in un GROUP BY quando non è presente alcun valore aggregato MAX o MIN (o HAVING MAX/MAX) nell'elenco SELECT. Prima di questa modifica, Spanner caricava la colonna non raggruppata aggiuntiva, 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 viene introdotto un operatore cross apply dai join 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 eseguendo il push di più calcoli tramite JOIN.

    Esegue il push di più calcoli che potrebbero includere una sottoquery o la creazione di strutture tramite join. Ciò migliora le prestazioni delle query in alcuni modi, ad esempio: È possibile eseguire più calcoli in modo distribuito e anche più operazioni che dipendono dai calcoli inviati possono essere spinte verso il basso. Ad esempio, la query ha un limite e l'ordinamento dipende da questi calcoli, quindi il limite può essere anche inviato 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 determinate circostanze.
  • Migliora le prestazioni di un'analisi in base a GROUP BY in determinate situazioni.

Versione 1: 18 giugno 2019

  • Include molte ottimizzazioni basate su regole, come il push-down predicato, il limite pushdown, i join ridondanti e la rimozione di espressioni ridondanti, solo per citarne alcune.

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

Passaggi successivi