Scenari di utilizzo per Query Store - Database di Azure per PostgreSQL - Server flessibile
SI APPLICA A: 
Database di Azure per PostgreSQL - Server flessibile
È 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 di carichi di lavoro improvvisati.
Identificare e ottimizzare le query con costo elevato
Identificare le query in esecuzione da più tempo
Usare le viste di Query Store nel database azure_sys del server per identificare rapidamente le query con esecuzione più lunga. Queste query tendono in genere a usare la maggior parte delle 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.
Otimizzare le query dispendiose
Quando si identifica una query con prestazioni non ottimali, l'azione eseguita dipende dalla natura del problema. Alcune di queste azioni potrebbero essere:
- 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, anziché farlo 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, prima o dopo la migrazione. Scenari di esempio per l'uso di Query Store per valutare l'impatto delle modifiche apportate alle prestazioni del carico di lavoro:
- Migrazione tra le versioni principali di PostgreSQL.
- Implementazione di una nuova versione di un'applicazione.
- Modifica della quantità di risorse concesse al server.
- Modifica di uno dei parametri del server che influiscono sul comportamento del server.
- Creazione di indici mancanti nelle tabelle a cui fanno riferimento query con costo elevato.
- Migrazione dal Database di Azure per PostgreSQL - Server singolo al Database di Azure per PostgreSQL - Server flessibile.
In tutti questi scenari applicare il flusso di lavoro seguente:
- Eseguire il carico di lavoro con Query Store prima della modifica pianificata per generare una baseline delle prestazioni.
- Applicare le modifiche desiderate in un momento controllato.
- Continuare a eseguire il carico di lavoro per il tempo necessario per generare un'immagine delle prestazioni del sistema dopo la modifica.
- Confrontare i risultati ottenuti prima e dopo la modifica.
- Decidere se mantenere la modifica o eseguire il rollback.
Identificare e migliorare carichi di lavoro improvvisati
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.