Best practice di SQL

Come descritto in Piani di esecuzione delle query, il compilatore SQL trasforma un'istruzione SQL in un piano di esecuzione di query, utilizzati per ottenere i risultati della query. Questa pagina descrive le best practice per la creazione di istruzioni SQL per aiutare Spanner a trovare piani di esecuzione efficienti.

Le istruzioni SQL di esempio mostrate in questa pagina utilizzano lo schema di esempio seguente:

GoogleSQL

CREATE TABLE Singers (
 SingerId   INT64 NOT NULL,
 FirstName  STRING(1024),
 LastName   STRING(1024),
 SingerInfo BYTES(MAX),
 BirthDate  DATE
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
 SingerId     INT64 NOT NULL,
 AlbumId      INT64 NOT NULL,
 AlbumTitle   STRING(MAX),
 ReleaseDate  DATE
) PRIMARY KEY (SingerId, AlbumId),
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Per il riferimento SQL completo, consulta Sintassi delle dichiarazioni Funzioni e operatori, e sintassi e struttura legislativa.

PostgreSQL

CREATE TABLE Singers (
 SingerId   BIGINT PRIMARY KEY,
 FirstName  VARCHAR(1024),
 LastName   VARCHAR(1024),
 SingerInfo BYTEA,
 BirthDate  TIMESTAMPTZ
);

CREATE TABLE Albums (
 SingerId        BIGINT NOT NULL,
 AlbumId         BIGINT NOT NULL,
 AlbumTitle      VARCHAR(1024),
 ReleaseDate     DATE,
 PRIMARY KEY(SingerId, AlbumId),
 FOREIGN KEY (SingerId) REFERENCES Singers(SingerId)
) INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Per ulteriori informazioni, consulta Il linguaggio PostgreSQL in Spanner.

Utilizzare parametri di ricerca

Spanner supporta i parametri di query per aumentare le prestazioni e contribuire a impedire l'inserimento di SQL quando le query vengono costruite utilizzando l'input dell'utente. Puoi utilizzare i parametri di query come sostituti di espressioni arbitrarie, ma non come sostituti di identificatori, nomi di colonne, nomi di tabelle o altre parti della query.

I parametri possono essere visualizzati ovunque sia previsto un valore letterale. Uguale nome del parametro può essere utilizzato più di una volta in una singola istruzione SQL.

In sintesi, i parametri di query supportano l'esecuzione delle query nei seguenti modi:

• Piani preottimizzati: le query che utilizzano parametri possono essere eseguite più rapidamente su a ogni chiamata, perché la parametrizzazione semplifica Spanner per memorizzare nella cache il piano di esecuzione.
• Composizione semplificata delle query: non è necessario applicare i caratteri di escape ai valori di stringa quando li fornisci nei parametri di query. I parametri di ricerca riducono inoltre il rischio errori di sintassi.
• Sicurezza: i parametri di query rendono le tue query più sicure proteggendoti da vari attacchi di SQL injection. Questa protezione è particolarmente importante per le query create a partire dall'input utente.

Informazioni su come Spanner esegue le query

Nota: Spanner Studio (in precedenza Query nella console Google Cloud) supporta le operazioni SQL, DML e DDL in un unico editor. Per ulteriori informazioni, consulta Gestire i dati utilizzando la console Google Cloud.

Spanner ti consente di eseguire query sui database utilizzando istruzioni SQL declarative che specificano i dati che vuoi recuperare. Se vuoi capire in che modo Spanner ottiene i risultati, esamina il piano di esecuzione della query. R il piano di esecuzione della query visualizza il costo di calcolo associato a ogni passaggio della query. Utilizzando questi costi, puoi eseguire il debug dei problemi di prestazioni delle query e ottimizzare la query. Per scoprire di più, consulta Piani di esecuzione delle query.

Puoi recuperare i piani di esecuzione delle query tramite la console Google Cloud oppure le librerie client.

Per ottenere un piano di esecuzione per una query specifica utilizzando la console Google Cloud, segui questi passaggi:

1. Apri la pagina Istanze Spanner.

   Vai alle istanze Spanner

2. Seleziona i nomi dell'istanza Spanner e del database su cui eseguire query.

3. Fai clic su Spanner Studio nel pannello di navigazione a sinistra.

4. Digita la query nel campo di testo e fai clic su Esegui query.

5. Fai clic su Spiegazione
   . La console Google Cloud mostra di esecuzione del piano di controllo per la tua query.

   

Per maggiori informazioni su come comprendere i piani visivi e utilizzarli per il debug vedi Ottimizzare una query utilizzando il visualizzatore del piano di query.

Puoi anche visualizzare esempi di piani di query storici e confrontare il rendimento di una query nel tempo per determinate query. Per scoprire di più, consulta Piani di query campionati.

Utilizza indici secondari

Come altri database relazionali, Spanner offre indici secondari, per il recupero dei dati mediante un'istruzione SQL l'interfaccia di lettura di Spanner. Il modo più comune per recuperare i dati da un indice è utilizzare Spanner Studio. Utilizzo di un indice secondario in una query SQL consente di specificare come vuoi che Spanner ottenga i risultati. La specifica di un indice secondario può velocizzare l'esecuzione delle query.

Ad esempio, supponiamo di voler recuperare gli ID di tutti i cantanti con un determinato cognome. Un modo per scrivere una query SQL di questo tipo è:

SELECT s.SingerId
FROM Singers AS s
WHERE s.LastName = 'Smith';

Questa query restituirà i risultati previsti, ma potrebbe richiedere un molto tempo per restituire i risultati. I tempi dipendono dal numero di righe nella tabella Singers e da quante soddisfano il predicato WHERE s.LastName = 'Smith'. Se non esiste un indice secondario che contiene la colonna LastName da leggere, il piano di query leggerà l'intera tabella Singers per trovare le righe corrispondenti al predicato. Lettura integrale tabella è chiamata scansione completa della tabella. Una ricerca completa della tabella è un modo costoso per ottenere i risultati quando la tabella contiene solo una piccola percentuale di Singers con quel cognome.

Puoi migliorare le prestazioni di questa query definendo un indice secondario sulla colonna del cognome:

CREATE INDEX SingersByLastName ON Singers (LastName);

Poiché l'indice secondario SingersByLastName contiene la tabella indicizzata colonna LastName e la colonna di chiave primaria SingerId, Spanner può recupera tutti i dati dalla tabella indice molto più piccola anziché analizzare tabella Singers completa.

In questo scenario, Spanner utilizza automaticamente indicizzare SingersByLastName durante l'esecuzione della query (purché tre giorni siano passato dalla creazione del database; vedi Una nota sui nuovi database). Tuttavia, è meglio indicare esplicitamente a Spanner di usare quell'indice specificando un'istruzione di indice nella clausola FROM:

GoogleSQL

SELECT s.SingerId
FROM Singers@{FORCE_INDEX=SingersByLastName} AS s
WHERE s.LastName = 'Smith';

PostgreSQL

 SELECT s.SingerId
FROM Singers /*@ FORCE_INDEX=SingersByLastName */ AS s
WHERE s.LastName = 'Smith';

Ora supponi di voler recuperare anche il nome del cantante, oltre al ID. Anche se la colonna FirstName non è contenuta nell'indice, devi specificare comunque la direttiva "index" come prima:

GoogleSQL

SELECT s.SingerId, s.FirstName
FROM Singers@{FORCE_INDEX=SingersByLastName} AS s
WHERE s.LastName = 'Smith';

PostgreSQL

SELECT s.SingerId, s.FirstName
FROM Singers /*@ FORCE_INDEX=SingersByLastName */ AS s
WHERE s.LastName = 'Smith';

Puoi comunque ottenere un vantaggio in termini di prestazioni dall'uso dell'indice perché Spanner non deve eseguire una scansione completa della tabella durante l'esecuzione del piano di query. Invece, seleziona il sottoinsieme di righe che soddisfa il predicato da SingersByLastName indice ed esegue una ricerca nella tabella di base Singers per recuperare il primo solo per quel sottoinsieme di righe.

Se non vuoi che Spanner debba recuperare righe dalla tabella di base, puoi memorizzare una copia della colonna FirstName nell'indice stesso:

GoogleSQL

CREATE INDEX SingersByLastName ON Singers (LastName) STORING (FirstName);

PostgreSQL

CREATE INDEX SingersByLastName ON Singers (LastName) INCLUDE (FirstName);

Utilizzo di una clausola STORING (per il dialetto GoogleSQL) o di una clausola INCLUDE (per il dialetto PostgreSQL) come questo costa spazio di archiviazione aggiuntivo, offre i seguenti vantaggi:

• Query SQL che utilizzano l'indice e selezionano le colonne archiviate in STORING o La clausola INCLUDE non richiede un join aggiuntivo alla tabella di base.
• Le chiamate di lettura che utilizzano l'indice possono leggere le colonne archiviate in STORING o Clausola INCLUDE.

Gli esempi precedenti illustrano come gli indici secondari possano velocizzare le query quando le righe scelte dalla clausola WHERE di una query possono essere identificate rapidamente utilizzando l'indice secondario.

Un altro scenario in cui gli indici secondari possono offrire i vantaggi in termini di prestazioni riguardano determinate query che restituiscono risultati ordinati. Per Ad esempio, supponi di voler recuperare tutti i titoli degli album e le relative date di uscita. in ordine crescente per la data di rilascio e in ordine decrescente per il titolo dell'album. Potresti scrivere una query SQL come segue:

SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums AS a
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;

Senza un indice secondario, questa query richiede un passaggio di ordinamento potenzialmente costoso nel piano di esecuzione. Puoi velocizzare l'esecuzione delle query definendo questo indice secondario:

CREATE INDEX AlbumsByReleaseDateTitleDesc on Albums (ReleaseDate, AlbumTitle DESC);

Quindi, riscrivi la query in modo da utilizzare l'indice secondario:

GoogleSQL

SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums@{FORCE_INDEX=AlbumsByReleaseDateTitleDesc} AS a
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;

PostgreSQL

SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums /*@ FORCE_INDEX=AlbumsByReleaseDateTitleDesc */ AS s
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;

Questa definizione di query e indice soddisfa entrambi i seguenti criteri:

• Per rimuovere il passaggio di ordinamento, assicurati che l'elenco delle colonne nell'ORDER BY è un prefisso dell'elenco delle chiavi di indice.
• Per evitare di unire i dati dalla tabella di base al recupero delle colonne mancanti, assicurati che l'indice copra tutte le colonne della tabella utilizzate dalla query.

Sebbene gli indici secondari possano velocizzare le query comuni, la loro aggiunta può aumentare la latenza delle operazioni di commit, perché ogni indice secondario richiede in genere il coinvolgimento di un nodo aggiuntivo in ogni commit. Per la maggior parte dei carichi di lavoro, è sufficiente avere alcuni indici secondari. Tuttavia, devi valuta se ti interessa di più la latenza di lettura o scrittura e valuta operazioni sono fondamentali per il carico di lavoro. Esegui il benchmarking del tuo carico di lavoro per assicurarti che funzioni come previsto.

Per il riferimento completo sugli indici secondari, consulta in Indici secondari.

Ottimizza le scansioni

Per alcune query Spanner potrebbe essere utile utilizzare un metodo di elaborazione orientato ai batch durante la scansione dei dati anziché il metodo di elaborazione più comune orientato alle righe. L'elaborazione delle scansioni in batch è un modo più efficiente elaborare grandi volumi di dati contemporaneamente e consentire alle query di raggiungere di utilizzo e latenza della CPU ridotti.

L'operazione di scansione di Spanner avvia sempre l'esecuzione in modalità orientata alle righe. Durante questo periodo, Spanner raccoglie diversi metriche di runtime. Spanner applica quindi un insieme di euristiche basate sul risultato di queste metriche per determinare la modalità di scansione ottimale. Quando appropriata, Spanner passa a una modalità di elaborazione orientata al batch per migliorare la velocità effettiva e le prestazioni della scansione.

Casi d'uso comuni

Le query con le seguenti caratteristiche in genere traggono vantaggio dall'uso di elaborazione orientata al batch:

• Scansioni di grandi dimensioni su dati aggiornati raramente.
• Scansioni con predicati su colonne a larghezza fissa.
• Scansioni con conteggi lunghi. (una ricerca utilizza un indice per recuperare i record).

Casi d'uso senza miglioramenti delle prestazioni

Non tutte le query traggono vantaggio dall'elaborazione orientata al batch. I seguenti tipi di query hanno un rendimento migliore con l'elaborazione di scansioni orientate alle righe:

• Query di ricerca point: query che recuperano solo una riga.
• Query di scansione ridotte: analisi delle tabelle che analizzano solo alcune righe, a meno che non siano state conteggi di ricerca elevati.
• Query che utilizzano LIMIT.
• Query che leggono dati con un tasso di abbandono elevato: query in cui più del 10% circa dei dati letti viene aggiornato di frequente.
• Query con righe contenenti valori di grandi dimensioni: le righe con valori di grandi dimensioni sono quelle contenenti valori superiori a 32.000 byte (precompressione) in una singola colonna.

Come controllare il metodo di scansione utilizzato da una query

Per verificare se la query utilizza l'elaborazione orientata al batch, l'elaborazione orientata alle righe, o passa automaticamente da un metodo di scansione all'altro:

1. Vai alla pagina Istanze di Spanner nella console Google Cloud.

   Vai alla pagina Istanze

2. Fai clic sul nome dell'istanza con la query che vuoi esaminare.

3. Nella tabella Database, fai clic sul database con la query che ti interessa. per indagare.

4. Nel menu di navigazione, fai clic su Spanner Studio.

5. Apri una nuova scheda facendo clic su Nuova scheda dell'editor SQL o Nuova scheda.

6. Quando viene visualizzato l'editor delle query, scrivi la query.

7. Fai clic su Esegui.

   Spanner esegue la query e mostra i risultati.

8. Fai clic sulla scheda Spiegazione sotto l'editor di query.

   Spanner mostra un visualizzatore del piano di esecuzione del piano di query. Ogni scheda sul grafico rappresenta un iteratore.

9. Fai clic sulla scheda dell'iteratore Scansione tabella per aprire un riquadro informativo.

   Il riquadro delle informazioni mostra informazioni contestuali sulla scansione selezionata. Il metodo di scansione viene mostrato in questa scheda. Automatico indica che Spanner determina l'analisi . Altri valori possibili sono Vectorized per orientati al batch e Scalar per l'elaborazione orientata alle righe.

   

Come applicare in modo forzato il metodo di scansione utilizzato da una query

Per ottimizzare le prestazioni delle query, Spanner sceglie il metodo di scansione ottimale per la query. Ti consigliamo di utilizzare questo metodo di scansione predefinito. Tuttavia, potrebbero verificarsi casi in cui potrebbe essere utile applicare tipo di metodo di scansione.

Come applicare la scansione orientata al batch

Puoi applicare la scansione basata su batch a livello di tabella e di istruzioni.

Per applicare il metodo di scansione batch a livello di tabella, utilizza un suggerimento tabella nella query:

GoogleSQL

  SELECT ...
  FROM (t1@{SCAN_METHOD=BATCH} JOIN t2 ON ...)
  WHERE ...

PostgreSQL

  SELECT ...
  FROM (t1/*@ scan_method=batch */ JOIN t2 on ...)
  WHERE ...

Per applicare il metodo di scansione basato su batch a livello di dichiarazione, utilizza un indicazione di dichiarazione nella query:

GoogleSQL

  @{SCAN_METHOD=BATCH}
  SELECT ...
  FROM ...
  WHERE ...

PostgreSQL

  /*@ scan_method=batch */
  SELECT ...
  FROM ...
  WHERE ...

Come disattivare la scansione automatica e applicare la scansione orientata alle righe

Anche se sconsigliamo di disattivare il metodo di scansione automatica impostato da Spanner, puoi decidere di disabilitarlo e utilizzare metodo di scansione orientato alle righe per la risoluzione dei problemi, ad esempio la diagnosi una latenza di pochi millisecondi.

Per disattivare il metodo di scansione automatica e applicare l'elaborazione delle righe a livello di tabella, utilizza un suggerimento tabella nella query:

GoogleSQL

  SELECT ...
  FROM (t1@{SCAN_METHOD=ROW} JOIN t2 ON ...)
  WHERE ...

PostgreSQL

  SELECT ...
  FROM (t1/*@ scan_method=row */ JOIN t2 on ...)
  WHERE ...

Per disabilitare il metodo di scansione automatica e applicare l'elaborazione delle righe all'istruzione utilizza un suggerimento di istruzioni nella query:

GoogleSQL

  @{SCAN_METHOD=ROW}
  SELECT ...
  FROM ...
  WHERE ...

PostgreSQL

  /*@ scan_method=row */
  SELECT ...
  FROM ...
  WHERE ...

Ottimizza le ricerche di chiavi per l'intervallo

Un uso comune di una query SQL è leggere più righe da Spanner basate su un elenco di chiavi note.

Le best practice riportate di seguito ti aiutano a scrivere query efficienti quando recuperi i dati in base a una serie di chiavi:

• Se l'elenco delle chiavi è sparso e non adiacente, utilizza parametri di ricerca e UNNEST per creare la tua query.

  Ad esempio, se il tuo elenco di chiavi è {1, 5, 1000}, scrivi la query come segue:

  GoogleSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key IN UNNEST (@KeyList)

  PostgreSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key IN UNNEST ($1)

  Note:

  • L'operatore di array UNNEST appiattisce un di input in righe di elementi.

  • Il parametro di query, che è @KeyList per GoogleSQL e $1 per PostgreSQL, possono accelerare la query come discusso della best practice precedente.

• Se l'elenco delle chiavi è adiacente ed entro un intervallo, specifica il valore minimo e limiti più elevati dell'intervallo di chiavi nella clausola WHERE.

  Ad esempio, se l'elenco di chiavi è {1,2,3,4,5}, costruisci la query come segue:

  GoogleSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key BETWEEN @min AND @max

  Nota: in questo caso, @min e @max sono parametri di ricerca associati alla rispettivamente i valori 1 e 5.

  PostgreSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key BETWEEN $1 AND $2

  Nota: in questo caso, $1 e $2 sono parametri di query associati rispettivamente ai valori 1 e 5.

  Questa query è più efficiente solo se le chiavi nell'intervallo di chiavi sono adiacenti. In altre parole, se l'elenco di chiavi è {1, 5, 1000}, non specificare i limiti inferiore e superiore come nella query precedente perché la query risultante esaminerà tutti i valori compresi tra 1 e 1000.

Ottimizzare i join

Le operazioni di join possono essere costose perché possono aumenta il numero di righe che deve essere analizzata dalla query, ottenendo per eseguire query più lente. Oltre alle tecniche che utilizzi abitualmente in altri database relazionali per ottimizzare le query di join, ecco alcune per un JOIN più efficiente quando si utilizza Spanner SQL:

• Se possibile, unisci i dati in tabelle con interleaving in base alla chiave primaria. Ad esempio:

  SELECT s.FirstName, a.ReleaseDate
  FROM Singers AS s JOIN Albums AS a ON s.SingerId = a.SingerId;

  Le righe della tabella interlacciata Albums sono garantite per essere memorizzate fisicamente nelle stesse suddivisioni della riga principale in Singers, come discusso in Schema e modello di dati. Pertanto, le unioni possono essere completate localmente senza inviare molti dati sulla rete.

• Utilizza la direttiva join se vuoi forzare l'ordine dell'unione. Ad esempio:

  GoogleSQL

  SELECT *
  FROM Singers AS s JOIN@{FORCE_JOIN_ORDER=TRUE} Albums AS a
  ON s.SingerId = a.Singerid
  WHERE s.LastName LIKE '%x%' AND a.AlbumTitle LIKE '%love%';

  PostgreSQL

  SELECT *
  FROM Singers AS s JOIN/*@ FORCE_JOIN_ORDER=TRUE */ Albums AS a
  ON s.SingerId = a.Singerid
  WHERE s.LastName LIKE '%x%' AND a.AlbumTitle LIKE '%love%';

  La direttiva join FORCE_JOIN_ORDER indica a Spanner di utilizzare l'ordine di join specificato nella query (ovvero Singers JOIN Albums, non Albums JOIN Singers). I risultati restituiti sono gli stessi, indipendentemente dall'ordine scelto da Spanner. Tuttavia, ti consigliamo di utilizzare questa direttiva di join se nel piano di query noti che Spanner ha modificato l'ordine di join e ha causato conseguenze indesiderate, ad esempio risultati intermedi più grandi o ha perso opportunità di ricerca delle righe.

• Utilizza una direttiva join per scegliere un'implementazione dell'unione. Quando utilizzi SQL per eseguire query su più tabelle, Spanner utilizza automaticamente un metodo di join che ha maggiori probabilità di rendere la query più efficiente. Tuttavia, Google consiglia da testare con diversi algoritmi di join. La scelta dell'algoritmo di join corretto può migliorare la latenza, il consumo di memoria o entrambi. Questa query dimostra la sintassi per usare un'istruzione JOIN con il suggerimento JOIN_METHOD per scegliere un HASH JOIN:

  GoogleSQL

  SELECT *
  FROM Singers s JOIN@{JOIN_METHOD=HASH_JOIN} Albums AS a
  ON a.SingerId = a.SingerId

  PostgreSQL

  SELECT *
  FROM Singers s JOIN/*@ JOIN_METHOD=HASH_JOIN */ Albums AS a
  ON a.SingerId = a.SingerId

• Se utilizzi un HASH JOIN o un APPLY JOIN e hai una clausola WHERE molto selettiva su un lato del JOIN, inserisci la tabella che genera il numero più piccolo di righe come prima tabella nella clausola FROM della join. Questa struttura è utile perché attualmente in HASH JOIN, Spanner sceglie sempre la tabella laterale sinistra come build e tavolo laterale destro come sonda. Allo stesso modo, per APPLY JOIN, Spanner sceglie il tavolino di sinistra come esterno e quello di destra come interno. Scopri di più su questi tipi di join: Hash join e Richiedi adesione.

• Per le query fondamentali per il carico di lavoro, specifica la query più performante e l'ordine di join nelle istruzioni SQL per una maggiore coerenza le prestazioni dei dispositivi.

Evitare letture di grandi dimensioni all'interno delle transazioni di lettura/scrittura

Le transazioni di lettura/scrittura consentono una sequenza di zero o più legge o query SQL e può includere un insieme di mutazioni prima di una chiamata eseguire il commit. Per mantenere la coerenza dei dati, Spanner acquisisce i blocchi durante la lettura e la scrittura di righe nelle tabelle e negli indici. Per maggiori informazioni sulla chiusura, consulta Vita di letture e scritture.

A causa del funzionamento dei blocchi in Spanner, l'esecuzione di una query SQL o di lettura che legge un numero elevato di righe (ad esempio SELECT * FROM Singers) significa che nessun'altra transazione può scrivere nelle righe che hai letto fino a quando la transazione non viene confermata o interrotta.

Inoltre, poiché la transazione sta elaborando un numero elevato di righe, richiedere più tempo rispetto a una transazione che legge un intervallo di righe molto più ridotto (ad esempio SELECT LastName FROM Singers WHERE SingerId = 7), che ulteriormente aggrava il problema e riduce la velocità effettiva del sistema.

Pertanto, cerca di evitare letture di grandi dimensioni (ad esempio scansioni complete della tabella o operazioni di join massicce) nelle tue transazioni, a meno che tu non voglia accettare un throughput di scrittura inferiore.

In alcuni casi, il seguente pattern può produrre risultati migliori:

1. Esegui letture di grandi dimensioni all'interno di una transazione di sola lettura. Le transazioni di sola lettura consentono una maggiore velocità effettiva aggregata perché non utilizzare blocchi.
2. (Facoltativo) Esegui le eventuali elaborazioni richieste per i dati che hai appena letto.
3. Avvia una transazione di lettura/scrittura.
4. Verifica che le righe critiche non abbiano modificato i valori dall'esecuzione la transazione di sola lettura del passaggio 1.
   • Se le righe sono state modificate, esegui il rollback della transazione e ricomincia da passaggio 1.
   • Se è tutto a posto, esegui il commit delle mutazioni.

Un modo per assicurarti di evitare letture di grandi dimensioni nelle transazioni di lettura/scrittura è esaminare i piani di esecuzione generati dalle query.

Usa ORDER BY per assicurarti che l'ordine dei risultati SQL

Se prevedi un determinato ordinamento per i risultati di una query SELECT, inclusa esplicitamente la clausola ORDER BY. Ad esempio, se vuoi elenca tutti i cantanti in ordine di chiave primaria, utilizza questa query:

SELECT * FROM Singers
ORDER BY SingerId;

Spanner garantisce l'ordinamento dei risultati solo se la clausola ORDER BY è presente nella query. In altre parole, considera questa query senza il valore ORDER BY:

SELECT * FROM Singers;

Spanner non garantisce che i risultati di questa query vengano nell'ordine chiave primaria. Inoltre, l'ordine dei risultati può cambiare in qualsiasi momento e non è garantita in modo coerente tra le varie chiamate. Se una query contiene una clausola ORDER BY e Spanner utilizza un indice che fornisce l'ordine richiesto, Spanner non ordina esplicitamente i dati. Pertanto, non preoccuparti dell'impatto sul rendimento dell'inclusione di questa clausola. Puoi controllare se un'operazione di ordinamento esplicita è inclusa nell'esecuzione esaminando il piano di query.

Utilizza STARTS_WITH anziché LIKE

Poiché Spanner non valuta i pattern LIKE con parametri fino al momento dell'esecuzione, deve leggere tutte le righe e valutarle in base all'espressione LIKE per filtrare le righe che non corrispondono.

Quando un pattern LIKE ha il formato foo% (ad esempio, inizia con un stringa e termina con una singola percentuale con carattere jolly) e la colonna è indicizzata, utilizza STARTS_WITH anziché LIKE. Questo consente a Spanner di ottimizzare in modo più efficace l'esecuzione della query e il piano d'azione.

Sconsigliati:

GoogleSQL

SELECT a.AlbumTitle FROM Albums a
WHERE a.AlbumTitle LIKE @like_clause;

Nota: questo esempio presuppone che @like_clause sia associato a 'Love%'.

PostgreSQL

SELECT a.AlbumTitle FROM Albums a
WHERE a.AlbumTitle LIKE $1;

Nota: questo esempio presuppone che $2 sia associato a 'Love%'.

Consigliato:

GoogleSQL

SELECT a.AlbumTitle FROM Albums a
WHERE STARTS_WITH(a.AlbumTitle, @prefix);

Nota: questo esempio presuppone che @prefix sia associato a 'Love'. Questa query è più efficiente rispetto alla query precedente. Funziona più velocemente se un indice è definito su Albums.AlbumTitle.

PostgreSQL

SELECT a.AlbumTitle FROM Albums a
WHERE STARTS_WITH(a.AlbumTitle, $2);

Nota: questo esempio presuppone che $1 sia associato a 'Love'. Questa query è più efficiente della query precedente. Funziona più velocemente se un indice è definito su Albums.AlbumTitle.

Utilizza timestamp di commit

Se la tua applicazione deve eseguire query su dati scritti dopo un determinato periodo di tempo, Aggiungere colonne di timestamp di commit alle tabelle pertinenti. Timestamp del commit abilitare un'ottimizzazione Spanner che può ridurre l'I/O di query le cui clausole WHERE limitano i risultati alle righe scritte più di recente rispetto a un'ora specifica.

Scopri di più su questa ottimizzazione con database di dialetti GoogleSQL o con database di dialetti PostgreSQL.