Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
È possibile usare Query Store in svariati scenari, in cui è fondamentale garantire prestazioni dei carichi di lavoro prevedibili e tenerne traccia. Si considerino gli esempi seguenti:
- Identificare e ottimizzare le query con costo elevato.
- Eseguire test A/B.
- Identificare e migliorare carichi di lavoro improvvisati
Identificare e ottimizzare le query con costo elevato
Identificare query con esecuzione prolungata
Usare le viste di Query Store nel database azure_sys del server per identificare rapidamente le query con esecuzione più lunga. Queste query tendono 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 eseguire la risoluzione dei problemi con ambito 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. Ad esempio, sfruttare i vantaggi della parametrizzazione delle query e ridurre l'uso di SQL ad hoc. Implementare la logica ottimale durante la lettura dei dati, ad esempio applicando i filtri dei dati sul lato database, anziché farlo sul lato applicazione.
Eseguire 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.
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 un periodo di tempo sufficiente, in modo da avere un'idea chiara 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 dispongono di query dominanti che possono essere ottimizzate 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.