Condividi tramite

Scenari di utilizzo per Query Store

  • Articolo

SI APPLICA A: Database di Azure per PostgreSQL - Server singolo

Importante

Database di Azure per PostgreSQL - Server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per PostgreSQL - Server flessibile. Per altre informazioni sulla migrazione a Database di Azure per PostgreSQL - Server flessibile, vedere What's happening to Database di Azure per PostgreSQL Single Server?.

È possibile usare Query Store in svariati scenari, in cui è fondamentale garantire prestazioni dei carichi di lavoro prevedibili e tenerne traccia. Vedi gli esempi seguenti:

  • Identificazione e ottimizzazione delle query con costo più elevato
  • Test A/B
  • Prestazioni stabili durante gli aggiornamenti
  • Identificazione e miglioramento dei carichi di lavoro ad hoc

Identificare e ottimizzare le query con costo elevato

Identificare le query in esecuzione da più tempo

Usare la vista Informazioni dettagliate prestazioni query nel portale di Azure per identificare rapidamente le query in esecuzione da più tempo. Queste query in genere tendono a consumare una quantità considerevole di risorse. Ottimizzando le query in esecuzione da più tempo, è possibile migliorare le prestazioni liberando risorse che possono essere usate da altre query in esecuzione nel sistema.

Identificare le query con valori differenziali nelle prestazioni

Query Store seziona i dati delle prestazioni in intervalli di tempo che consentono di tenere traccia delle prestazioni di una query nel corso del tempo. In questo modo è possibile identificare esattamente quali query contribuiscono ad aumentare il tempo totale impiegato. Di conseguenza è possibile risolvere in modo mirato i problemi del carico di lavoro.

Ottimizzazione delle query con costo elevato

Quando si identifica una query con prestazioni non ottimali, l'azione eseguita dipende dalla natura del problema:

  • Vedere Raccomandazioni per le prestazioni per determinare se sono presenti indici suggeriti. In caso affermativo, creare l'indice e quindi usare Query Store per valutare le prestazioni delle query dopo aver creato l'indice.
  • Assicurarsi che le statistiche siano aggiornate per le tabelle sottostanti usate dalla query.
  • Considerare la possibilità di riscrivere le query con costo elevato. Sfruttare, ad esempio, i vantaggi della parametrizzazione delle query e ridurre l'uso di SQL dinamico. Implementare la logica ottimale durante la lettura dei dati, ad esempio applicando i filtri dei dati sul lato database, non sul lato applicazione.

Test A/B

Usare Query Store per confrontare le prestazioni del carico di lavoro prima e dopo la modifica di un'applicazione che si intende introdurre. Esempi di scenari per l'uso di Query Store per valutare l'impatto della modifica dell'ambiente o dell'applicazione sulle prestazioni del carico di lavoro:

  • Implementazione di una nuova versione di un'applicazione.
  • Aggiunta di altre risorse al server.
  • Creazione di indici mancanti nelle tabelle a cui fanno riferimento query con costo elevato.

In tutti questi scenari applicare il flusso di lavoro seguente:

  1. Eseguire il carico di lavoro con Query Store prima della modifica pianificata per generare una baseline delle prestazioni.
  2. Applicare le modifiche dell'applicazione in un momento controllato.
  3. Continuare a eseguire il carico di lavoro per il tempo necessario per generare un'immagine delle prestazioni del sistema dopo la modifica.
  4. Confrontare i risultati ottenuti prima e dopo la modifica.
  5. Decidere se mantenere la modifica o eseguire il rollback.

Identificare e migliorare i carichi di lavoro ad hoc

Alcuni carichi di lavoro non includono query dominanti che è possibile ottimizzare per migliorare le prestazioni complessive dell'applicazione. Questi carichi di lavoro sono in genere caratterizzati da un numero relativamente elevato di query univoche, ognuna delle quali consuma una parte delle risorse di sistema. Ogni query univoca viene eseguita raramente, quindi il consumo individuale del runtime non è critico. D'altra parte, dato che l'applicazione genera continuamente nuove query, una parte significativa delle risorse di sistema viene impiegata per la compilazione delle query, ma ciò non è l'ideale. In genere, questa situazione si verifica se l'applicazione genera query (invece di usare le stored procedure o le query con parametri) o se si basa su framework di mapping relazionale a oggetti che generano query per impostazione predefinita.

Se si ha il controllo del codice dell'applicazione, considerare la possibilità di riscrivere il livello di accesso ai dati per usare le stored procedure o le query con parametri. Tuttavia, questa situazione può essere anche migliorata senza modifiche all'applicazione, forzando la parametrizzazione delle query per l'intero database (tutte le query) o per i singoli modelli di query con lo stesso hash di query.

Passaggi successivi