Ottimizza il calcolo delle query

Questo documento fornisce le best practice per ottimizzare le prestazioni delle query.

Al termine della query, puoi visualizzare il piano di query nella console Google Cloud. Puoi anche richiedere i dettagli dell'esecuzione utilizzando le viste INFORMATION_SCHEMA.JOBS* o il metodo dell'API REST jobs.get.

Il piano di query include dettagli sulle fasi e sui passaggi delle query. Questi dettagli possono aiutarti a identificare modi per migliorare le prestazioni delle query. Ad esempio, se noti una fase che scrive molto più output rispetto alle altre, potrebbe significare che devi applicare un filtro prima nella query.

Per saperne di più sul piano di query e vedere esempi di come le informazioni sul piano di query possono aiutare a migliorare le prestazioni delle query, consulta Ottenere insight sulle prestazioni delle query. Dopo aver esaminato gli insight sulle prestazioni delle query, puoi ottimizzare ulteriormente la query eseguendo le seguenti attività:

Riduci i dati elaborati

Puoi ridurre i dati da elaborare utilizzando le opzioni descritte nelle sezioni seguenti.

Evita SELECT *

Best practice: controlla la proiezione eseguendo query solo sulle colonne necessarie.

La proiezione si riferisce al numero di colonne lette dalla query. La proiezione di colonne in eccesso comporta I/O aggiuntivi (sprechi) e materializzazione (risultati della scrittura).

  • Utilizza le opzioni di anteprima dei dati. Se stai sperimentando con i dati o esplorando i dati, utilizza una delle opzioni di anteprima dei dati anziché SELECT *.
  • Esegui query su colonne specifiche. L'applicazione di una clausola LIMIT a una query SELECT * non influisce sulla quantità di dati letti. Ti viene addebitato il costo per la lettura di tutti i byte dell'intera tabella e le query vengono conteggiate ai fini della quota del livello gratuito. Esegui la query solo sulle colonne necessarie. Ad esempio, utilizza SELECT * EXCEPT per escludere una o più colonne dai risultati.
  • Utilizza tabelle partizionate. Se hai bisogno di query su ogni colonna di una tabella, ma solo su un sottoinsieme di dati, considera le seguenti possibilità:

  • Utilizza SELECT * EXCEPT. Eseguire query su un sottoinsieme di dati o utilizzare SELECT * EXCEPT può ridurre notevolmente la quantità di dati letti da una query. Oltre al risparmio sui costi, le prestazioni vengono migliorate riducendo la quantità di I/O dei dati e la quantità di materializzazione richiesta per i risultati delle query.

    SELECT * EXCEPT (col1, col2, col5)
FROM mydataset.newtable

Evita un numero eccessivo di tabelle con caratteri jolly

Best practice: quando esegui query su tabelle con caratteri jolly, devi utilizzare il prefisso più granulare.

Utilizza caratteri jolly per eseguire query su più tabelle utilizzando istruzioni SQL concise. Le tabelle con caratteri jolly sono un insieme di tabelle che corrispondono all'espressione con caratteri jolly. Le tabelle con caratteri jolly sono utili se il set di dati contiene le seguenti risorse:

  • Più tabelle con nomi simili con schemi compatibili
  • Tabelle con sharding

Quando esegui una query su una tabella con funzione carattere jolly, specifica un carattere jolly (*) dopo il prefisso della tabella comune. Ad esempio, FROM bigquery-public-data.noaa_gsod.gsod194* esegue query su tutte le tabelle degli anni '40.

I prefissi più granulari hanno un rendimento migliore rispetto a quelli più brevi. Ad esempio, FROM bigquery-public-data.noaa_gsod.gsod194* ha un rendimento migliore di FROM bigquery-public-data.noaa_gsod.* perché meno tabelle corrispondono al carattere jolly.

Evita le tabelle con sharding in base alla data

Best practice: non utilizzare tabelle con sharding in base alla data (chiamate anche tabelle con nome della data) al posto delle tabelle partizionate nel tempo.

Le tabelle partizionate hanno un rendimento migliore rispetto alle tabelle con nome di data. Quando crei tabelle con sharding in base alla data, BigQuery deve conservare una copia dello schema e dei metadati per ogni tabella con nome della data. Inoltre, quando si utilizzano le tabelle con nome della data, potrebbe essere necessario BigQuery per verificare le autorizzazioni per ogni tabella sottoposta a query. Questa pratica aumenta anche l'overhead delle query e influisce sulle prestazioni delle query.

Evita l'utilizzo eccessivo delle tabelle

Best practice:evita di creare troppi shard di tabella. Se esegui lo sharding delle tabelle per data, utilizza invece tabelle partizionate in base al tempo.

Lo sharding delle tabelle si riferisce alla divisione di grandi set di dati in tabelle separate e all'aggiunta di un suffisso al nome di ogni tabella. Se esegui lo sharding delle tabelle in base alla data, utilizza invece tabelle partizionate in base all'ora.

A causa del basso costo dell'archiviazione BigQuery, non è necessario ottimizzare i costi delle tabelle come faresti in un sistema di database relazionale. La creazione di un numero elevato di shard di tabella ha effetti sulle prestazioni che superano eventuali vantaggi in termini di costi.

Le tabelle con sharding richiedono BigQuery per mantenere schema, metadati e autorizzazioni per ogni shard. A causa dell'overhead aggiuntivo necessario per gestire le informazioni su ogni shard, le tabelle con overheadsing possono influire sulle prestazioni delle query.

La quantità e l'origine dei dati letti da una query possono influire sulle prestazioni e sui costi delle query.

Elimina le query partizionate

Best practice: quando esegui query su una tabella partizionata, per filtrare con le partizioni nelle tabelle partizionate, utilizza le seguenti colonne:

  • Per le tabelle partizionate per la fase di importazione, utilizza la pseudo colonna _PARTITIONTIME
  • Per le tabelle partizionate, ad esempio quelle basate su colonne con unità di tempo e con un intervallo di numeri interi, utilizza la colonna di partizionamento.

Per le tabelle partizionate in unità di tempo, filtrare i dati con _PARTITIONTIME o la colonna di partizionamento consente di specificare una data o un intervallo di date. Ad esempio, la seguente clausola WHERE utilizza la pseudo colonna _PARTITIONTIME per specificare le partizioni tra il 1° gennaio 2016 e il 31 gennaio 2016:

WHERE _PARTITIONTIME
BETWEEN TIMESTAMP("20160101")
AND TIMESTAMP("20160131")

La query elabora i dati solo nelle partizioni indicate dall'intervallo di date. Il filtro delle partizioni migliora le prestazioni delle query e riduce i costi.

Riduci i dati prima di utilizzare JOIN

Best practice: riduci la quantità di dati elaborati prima di una clausola JOIN eseguendo le aggregazioni.

L'utilizzo di una clausola GROUP BY con funzioni aggregate richiede un'elevata capacità di calcolo, poiché questi tipi di query utilizzano lo shuffling. Poiché queste query richiedono un'elevata intensità di calcolo, devi utilizzare una clausola GROUP BY solo quando necessario.

Per le query con GROUP BY e JOIN, esegui l'aggregazione nelle prime fasi della query per ridurre la quantità di dati elaborati. Ad esempio, la seguente query esegue un comando JOIN su due tabelle di grandi dimensioni senza alcun filtro preliminare:

WITH
  users_posts AS (
  SELECT *
  FROM
    `bigquery-public-data`.stackoverflow.comments AS c
  JOIN
    `bigquery-public-data`.stackoverflow.users AS u
  ON
    c.user_id = u.id
  )
SELECT
  user_id,
  ANY_VALUE(display_name) AS display_name,
  ANY_VALUE(reputation) AS reputation,
  COUNT(text) AS comments_count
FROM users_posts
GROUP BY user_id
ORDER BY comments_count DESC
LIMIT 20;

Questa query preaggrega il numero di commenti che riduce la quantità di dati letti per JOIN:

WITH
  comments AS (
  SELECT
    user_id,
    COUNT(text) AS comments_count
  FROM
    `bigquery-public-data`.stackoverflow.comments
  WHERE
    user_id IS NOT NULL
  GROUP BY user_id
  ORDER BY comments_count DESC
  LIMIT 20
  )
SELECT
  user_id,
  display_name,
  reputation,
  comments_count
FROM comments
JOIN
  `bigquery-public-data`.stackoverflow.users AS u
ON
  user_id = u.id
ORDER BY comments_count DESC;

Usa la clausola WHERE

Best practice: utilizza una clausola WHERE per limitare la quantità di dati restituiti da una query. Quando possibile, utilizza le colonne BOOL, INT, FLOAT o DATE nella clausola WHERE.

Le operazioni sulle colonne BOOL, INT, FLOAT e DATE sono in genere più veloci delle operazioni sulle colonne STRING o BYTE. Se possibile, utilizza una colonna che usa uno di questi tipi di dati nella clausola WHERE per ridurre la quantità di dati restituiti dalla query.

Ottimizza le operazioni di query

Puoi ottimizzare le operazioni di query utilizzando le opzioni descritte nelle sezioni seguenti.

Evita di trasformare ripetutamente i dati

Best practice: se utilizzi SQL per eseguire operazioni ETL, evita i casi in cui trasformi ripetutamente gli stessi dati.

Ad esempio, se utilizzi SQL per tagliare le stringhe o estrarre dati utilizzando espressioni regolari, la soluzione migliore è materializzare i risultati trasformati in una tabella di destinazione. Le funzioni come le espressioni regolari richiedono un calcolo aggiuntivo. Eseguire query sulla tabella di destinazione senza l'overhead di trasformazione aggiuntivo è molto più efficiente.

Evita valutazioni multiple delle stesse CTE

Best practice: usa linguaggio procedurale, variabili, tabelle temporanee e tabelle con scadenza automatica per rendere i calcoli persistenti e utilizzarli in un secondo momento nella query.

Quando la query contiene espressioni tabella comuni (CTE) utilizzate in più punti della query, potrebbero finire per essere valutate a ogni riferimento. Lo strumento di ottimizzazione delle query tenta di rilevare le parti della query che potrebbero essere eseguite una sola volta, ma non sempre è possibile. Di conseguenza, l'utilizzo di una CTE potrebbe non contribuire a ridurre la complessità delle query interne e l'utilizzo delle risorse.

Puoi archiviare il risultato di una CTE in una variabile scalare o in una tabella temporanea, a seconda dei dati restituiti dalla CTE.

Evita join e sottoquery ripetuti

Best practice: evita di unire ripetutamente le stesse tabelle e utilizzare le stesse sottoquery.

Invece di unire ripetutamente i dati, potrebbe essere più efficiente utilizzare dati ripetuti nidificati per rappresentare le relazioni. I dati ripetuti nidificati consentono di risparmiare l'impatto sulle prestazioni della larghezza di banda di comunicazione richiesta da un join. Ti consente anche di risparmiare i costi di I/O che devi sostenere ripetutamente leggendo e scrivendo ripetutamente gli stessi dati. Per maggiori informazioni, consulta Utilizzare campi nidificati e ripetuti.

Analogamente, la ripetizione delle stesse sottoquery influisce sulle prestazioni tramite l'elaborazione di query ripetitive. Se utilizzi le stesse sottoquery in più query, valuta la possibilità di materializzare i risultati della sottoquery in una tabella. Poi utilizza i dati materializzati nelle query.

La materializzazione dei risultati della sottoquery migliora le prestazioni e riduce la quantità complessiva di dati letti e scritti da BigQuery. Il piccolo costo di archiviazione dei dati materializzati supera l'impatto sulle prestazioni dell'elaborazione di query e I/O ripetuti.

Ottimizza i pattern di unione

Best practice: per le query che uniscono i dati di più tabelle, ottimizza i pattern di join iniziando dalla tabella più grande.

Quando crei una query utilizzando una clausola JOIN, considera l'ordine in cui unisci i dati. Lo strumento di ottimizzazione delle query GoogleSQL determina la tabella su quale lato del join. Come best practice, posiziona prima la tabella con il maggior numero di righe, seguita dalla tabella con le meno righe, quindi posiziona le tabelle rimanenti riducendo le dimensioni.

Quando hai una tabella di grandi dimensioni sul lato sinistro di JOIN e una piccola sul lato destro di JOIN, viene creato un join di trasmissione. Un join broadcast invia tutti i dati nella tabella più piccola a ogni slot che elabora la tabella più grande. È consigliabile eseguire prima l'unione alla trasmissione.

Per visualizzare le dimensioni delle tabelle in JOIN, consulta Ottenere informazioni sulle tabelle.

Ottimizza la clausola ORDER BY

Best practice: quando utilizzi la clausola ORDER BY, assicurati di seguire le best practice:

  • Utilizza ORDER BY nella query più esterna o all'interno di clausole di finestra. Esegui il push di operazioni complesse alla fine della query. Inserire una clausola ORDER BY al centro di una query influisce notevolmente sulle prestazioni, a meno che non venga utilizzata in una funzione finestra.

    Un'altra tecnica per ordinare la query è eseguire il push di operazioni complesse, come espressioni regolari e funzioni matematiche, alla fine della query. Questa tecnica riduce i dati da elaborare prima dell'esecuzione delle operazioni complesse.

  • Utilizza una clausola LIMIT. Se ordina un numero molto elevato di valori ma non è necessario che vengano restituiti tutti, utilizza una clausola LIMIT. Ad esempio, la seguente query ordina un set di risultati molto grande e genera un errore Resources exceeded. La query viene ordinata in base alla colonna title in mytable. La colonna title contiene milioni di valori.

    SELECT
title
FROM
`my-project.mydataset.mytable`
ORDER BY
title;

    Per rimuovere l'errore, utilizza una query come la seguente:

    SELECT
title
FROM
`my-project.mydataset.mytable`
ORDER BY
title DESC
LIMIT
1000;

  • Utilizza una funzione di finestra. Se ordini un numero molto elevato di valori, utilizza una funzione finestra e limita i dati prima di chiamare la funzione finestra. Ad esempio, la seguente query elenca i dieci utenti di Stack Overflow più vecchi e il relativo ranking, con l'account meno recente che ha il ranking più basso:

    SELECT
id,
reputation,
creation_date,
DENSE_RANK() OVER (ORDER BY creation_date) AS user_rank
FROM bigquery-public-data.stackoverflow.users
ORDER BY user_rank ASC
LIMIT 10;

    L'esecuzione di questa query richiede circa 15 secondi. Questa query utilizza LIMIT alla fine della query, ma non nella funzione finestra DENSE_RANK() OVER. Per questo motivo, la query richiede che tutti i dati vengano ordinati su un singolo nodo worker.

    Devi invece limitare il set di dati prima di calcolare la funzione finestra al fine di migliorare le prestazioni:

    WITH users AS (
SELECT
id,
reputation,
creation_date,
FROM bigquery-public-data.stackoverflow.users
ORDER BY creation_date ASC
LIMIT 10)
SELECT
id,
reputation,
creation_date,
DENSE_RANK() OVER (ORDER BY creation_date) AS user_rank
FROM users
ORDER BY user_rank;

    L'esecuzione di questa query richiede circa 2 secondi e restituisce gli stessi risultati della query precedente.

    Un'avvertenza è che la funzione DENSE_RANK() classifica i dati nel giro di anni, quindi per il ranking dei dati che si estendono su più anni, queste query non forniscono risultati identici.

Suddividi le query complesse in query più piccole

Best practice: sfrutta le funzionalità di query con più istruzioni e le procedure archiviate per eseguire i calcoli che sono stati progettati come query complesse come più query di piccole dimensioni e più semplici.

Le query complesse, le funzioni REGEX e le sottoquery o i join a più livelli possono essere eseguiti lentamente e richiedono molte risorse. Cercare di adattare tutti i calcoli in un'unica istruzione SELECT di grandi dimensioni, ad esempio per creare una visualizzazione, a volte può essere un anti-pattern e può generare una query lenta e con un utilizzo intensivo di risorse. In casi estremi, il piano di query interne diventa così complesso che BigQuery non è in grado di eseguirlo.

La suddivisione di una query complessa consente di materializzare i risultati intermedi in variabili o tabelle temporanee. Puoi quindi utilizzare questi risultati intermedi in altre parti della query. È sempre più utile quando questi risultati sono necessari in più posizioni della query.

Spesso consente di esprimere meglio il vero intento delle parti della query con tabelle temporanee che sono i punti di materializzazione dei dati.

Utilizzare campi nidificati e ripetuti

Per informazioni su come denormalizzare l'archiviazione dei dati utilizzando campi nidificati e ripetuti, consulta Utilizzare campi nidificati e ripetuti.

Utilizza INT64 tipo di dati nei join

Best practice: utilizza i tipi di dati INT64 nei join anziché STRING tipi di dati per ridurre i costi e migliorare le prestazioni del confronto.

BigQuery non indicizza le chiavi primarie come i database tradizionali. Pertanto, maggiore è la larghezza della colonna di join, maggiore sarà il tempo necessario per il confronto. Di conseguenza, l'utilizzo dei tipi di dati INT64 nelle unioni è più economico ed efficiente rispetto all'utilizzo dei tipi di dati STRING.

Riduci output delle query

Puoi ridurre gli output delle query utilizzando le opzioni descritte nelle sezioni seguenti.

Materializza grandi insiemi di risultati

Best practice: valuta la possibilità di materializzare set di risultati di grandi dimensioni in una tabella di destinazione. Scrivere set di risultati di grandi dimensioni ha un impatto sulle prestazioni e sui costi.

BigQuery limita i risultati memorizzati nella cache a circa 10 GB compressi. Le query che restituiscono risultati di dimensioni maggiori superano questo limite e spesso generano il seguente errore: Response too large.

Questo errore si verifica spesso quando selezioni un numero elevato di campi da una tabella con una notevole quantità di dati. I problemi di scrittura dei risultati memorizzati nella cache possono verificarsi anche nelle query in stile ETL che normalizzano i dati senza riduzione o aggregazione.

Puoi risolvere il limite di dimensioni dei risultati memorizzati nella cache utilizzando le seguenti opzioni:

  • Utilizzare i filtri per limitare il set di risultati
  • Utilizza una clausola LIMIT per ridurre il set di risultati, soprattutto se utilizzi una clausola ORDER BY
  • Scrivi i dati di output in una tabella di destinazione

Puoi sfogliare i risultati utilizzando l'API REST di BigQuery. Per ulteriori informazioni, consulta la sezione Sfogliare i dati delle tabelle.

Utilizza BI Engine

Per accelerare ulteriormente le query SQL memorizzando nella cache i dati che utilizzi più di frequente, valuta la possibilità di aggiungere una prenotazione BI Engine al progetto in cui vengono calcolate le query. BigQuery BI Engine utilizza un motore di query vettoriale per accelerare le prestazioni delle query SELECT.

Evita pattern anti-SQL

Le seguenti best practice forniscono indicazioni su come evitare gli anti-pattern di query che influiscono sulle prestazioni in BigQuery.

Evita l'auto join

Best practice: anziché utilizzare i self-join, utilizza una funzione di finestra (analitica) o l'operatore PIVOT.

In genere, gli self-join vengono utilizzati per calcolare le relazioni dipendenti dalle righe. Il risultato dell'utilizzo di un self-join è che potenzialmente quadratico il numero di righe di output. Questo aumento dei dati di output può causare prestazioni scadenti.

Evitare unioni incrociate

Best practice:evita i join che generano più output che input. Quando è richiesto un valore CROSS JOIN, preaggrega i dati.

I cross join sono query in cui ogni riga della prima tabella è unita a ogni riga della seconda tabella, con chiavi non univoche su entrambi i lati. L'output peggiore è il numero di righe nella tabella di sinistra moltiplicato per il numero di righe nella tabella a destra. In casi estremi, la query potrebbe non essere completata.

Se il job di query viene completato, la spiegazione del piano di query mostra le righe di output e le righe di input. Puoi confermare un prodotto cartesiano modificando la query in modo che stampi il numero di righe su ciascun lato della clausola JOIN, raggruppate per chiave di join.

Per evitare problemi di prestazioni associati ai join che generano più output che input:

  • Utilizza una clausola GROUP BY per preaggregare i dati.
  • Utilizza una funzione finestra. Le funzioni finestra sono spesso più efficienti dell'uso di un cross join. Per ulteriori informazioni, consulta la sezione funzioni finestra.

Evita istruzioni DML che si aggiornano o inseriscono righe singole

Best practice: evita istruzioni DML che aggiornano o inseriscono righe singole. Raggruppa gli aggiornamenti e gli inserti.

L'utilizzo di istruzioni DML specifiche per punto tenta di trattare BigQuery come un sistema di elaborazione delle transazioni online (OLTP). BigQuery è incentrato sull'elaborazione analitica online (OLAP) utilizzando scansioni di tabelle e non ricerche di punti. Se hai bisogno di un comportamento simile a quello della soluzione OLTP (aggiornamenti o inserti su riga singola), valuta un database progettato per supportare i casi d'uso OLTP come Cloud SQL.

Le istruzioni DML di BigQuery sono destinate all'aggiornamento collettivo. Le istruzioni DML UPDATE e DELETE in BigQuery sono orientate a riscritture periodiche dei dati, non a mutazioni di singole righe. L'istruzione DML INSERT deve essere usata con parsimonia. Gli inserti consumano le stesse quotas di modifica dei job di caricamento. Se il tuo caso d'uso prevede inserti frequenti di singole righe, valuta la possibilità di eseguire il flusso di dati dei dati.

Se il raggruppamento delle istruzioni UPDATE restituisce molte tuple in query molto lunghe, potresti avvicinarti al limite di lunghezza delle query di 256 kB. Per aggirare il limite di lunghezza delle query, valuta se i tuoi aggiornamenti possono essere gestiti in base a criteri logici anziché in base a una serie di sostituzioni dirette di tuple.

Ad esempio, potresti caricare il set di record sostitutivi in un'altra tabella e poi scrivere l'istruzione DML per aggiornare tutti i valori nella tabella originale se le colonne non aggiornate corrispondono. Ad esempio, se i dati originali si trovano nella tabella t e gli aggiornamenti sono passati in fasi nella tabella u, la query sarà la seguente:

UPDATE
  dataset.t t
SET
  my_column = u.my_column
FROM
  dataset.u u
WHERE
  t.my_key = u.my_key

Filtrare i dati per dati distorti

Best practice: se la tua query elabora chiavi che sono fortemente distorte rispetto a pochi valori, filtra i dati il prima possibile.

Il disallineamento delle partizioni, chiamato a volte disallineamento dei dati, si verifica quando i dati vengono partizionati in partizioni di dimensioni molto non uguali. Questo crea uno squilibrio nella quantità di dati inviati tra gli slot. Non è possibile condividere le partizioni tra slot. Di conseguenza, se una partizione è particolarmente grande, potrebbe rallentare o persino causare l'arresto anomalo dello slot che elabora la partizione sovradimensionata.

Le partizioni diventano di grandi dimensioni quando la chiave di partizione ha un valore più spesso di qualsiasi altro valore. Ad esempio, raggruppare in base a un campo user_id in cui sono presenti molte voci per guest o NULL.

Quando le risorse di uno slot sono sovraccaricate, viene visualizzato un errore resources exceeded. Anche il raggiungimento del limite di shuffle per uno slot (2 TB di memoria compressa) determina la scrittura su disco dello shuffling, con un ulteriore impatto sulle prestazioni. I clienti con prezzi basati sulla capacità possono aumentare il numero di slot assegnati.

Se esamini il grafico di esecuzione delle query e noti una differenza significativa tra i tempi di calcolo medi e massimi, i dati potrebbero essere distorti.

Per evitare problemi di prestazioni derivanti dal disallineamento dei dati:

  • Utilizza una funzione aggregata approssimativa come APPROX_TOP_COUNT per determinare se i dati sono distorti.
  • Filtra i dati il prima possibile.

Join non bilanciati

Il disallineamento dei dati può verificarsi anche quando utilizzi clausole JOIN. Poiché BigQuery esegue lo shuffling dei dati su ogni lato del join, tutti i dati con la stessa chiave di join vengono inviati allo stesso shard. Questo shuffling può sovraccaricare lo slot.

Per evitare problemi di prestazioni associati ai join non bilanciati, puoi eseguire le seguenti attività:

  • Applica un pre-filtro delle righe della tabella con la chiave non bilanciata.
  • Se possibile, suddividi la query in due query.

  • Utilizza l'istruzione SELECT DISTINCT quando specifichi una sottoquery nella clausola WHERE per valutare i valori univoci dei campi solo una volta.

    Ad esempio, invece di utilizzare la seguente clausola che contiene un'istruzione SELECT:

    table1.my_id NOT IN (
  SELECT my_id
  FROM table2
  )

    Utilizza invece una clausola che contenga un'istruzione SELECT DISTINCT:

    table1.my_id NOT IN (
  SELECT DISTINCT my_id
  FROM table2
  )

Utilizza nomi alias per le colonne con nomi simili

Best practice: utilizza gli alias di colonna e tabella quando lavori con colonne con nomi simili nelle query, incluse le sottoquery.

Gli alias consentono di identificare le colonne e le tabelle a cui viene fatto riferimento oltre al riferimento iniziale della colonna. L'uso degli alias può aiutarti a comprendere e risolvere i problemi della query SQL, incluso l'individuazione delle colonne utilizzate nelle sottoquery.

Specifica i vincoli nello schema della tabella

Quando i dati della tabella contengono vincoli, specifica i vincoli nello schema della tabella. Il motore di query può ottimizzare i piani di query utilizzando vincoli di tabella.

Specifica i vincoli di chiave primaria e di chiave esterna

Devi specificare i vincoli chiave nello schema della tabella quando i dati della tabella soddisfano i requisiti di integrità dei dati dei vincoli di chiave primaria o di chiave esterna. Query Engine può utilizzare i vincoli chiave per ottimizzare i piani di query. Per informazioni dettagliate, consulta il post del blog Unire le ottimizzazioni con le chiavi primarie e le chiavi esterne di BigQuery.

BigQuery non controlla automaticamente l'integrità dei dati, quindi devi assicurarti che i dati soddisfino i vincoli specificati nello schema della tabella. Se non mantieni l'integrità dei dati nelle tabelle con vincoli specificati, i risultati della query potrebbero essere imprecisi.

Passaggi successivi