Come profilare le query SQL per prestazioni migliori

Al Servebolt, viviamo e respiriamoperformance .

Le prestazioni del database non fanno eccezione.

L'esecuzione di una query inefficiente dopo che un visitatore del sito Web ha fatto clic su un collegamento degraderà notevolmente l'esperienza dell'utente .Dovranno attendere l'intera durata dell'esecuzione della query lenta, che potrebbe richiedere diversi secondi, prima che venga eseguita qualsiasi altra azione, ad esempio il rendering della pagina. Questo tempo di attesa include non solo il tempo necessario per l'esecuzione della query, ma anche qualsiasi tempo aggiuntivo necessario per la pre-elaborazione e la post-elaborazione. Di conseguenza, una query mal progettata può rallentare in modo significativo le prestazioni complessive di un sito Web, determinando un'esperienza utente frustrante.

Time to First Byte (TTFB) è un modo per misurare il tempo necessario per ricevere il primo byte di dati dopo che un utente ha effettuato una richiesta a un sito web.È anche una metrica chiave utilizzata dai motori di ricerca nella valutazione dei siti. Quando viene attivata una query lenta, influirà negativamente sul TTFB. Maggiore è il tempo necessario per eseguire la query lenta, maggiore sarà il TTFB, con conseguente rallentamento delle prestazioni complessive del sito Web e un'esperienza utente meno soddisfacente.

In questa guida, ti illustreremo come profilare le query SQL, una parte cruciale del mantenimento delle prestazioni delle applicazioni Web che si basano sulle risposte del database. Questo è un processo che pone le basi per poter poi iniziare a lavorare sull'ottimizzazione di queste query per migliorarne le prestazioni.

Comprensione del profilo delle query SQL

Man mano che sviluppi un'applicazione Web e questa inizia a funzionare su scala più ampia, le query SQL che una volta venivano eseguite senza problemi possono causare problemi di prestazioni. In generale, tende ad esserci un numero crescente di query in esecuzione su una quantità crescente di dati con un numero crescente di richieste al secondo. E quando le prestazioni ne risentono, anche l'esperienza che i tuoi utenti hanno quando interagiscono con il tuo sito, software o servizio.

Il profilo delle query è un modo per analizzare le query del database, valutarne le prestazioni e identificare potenziali problemi.

Analizzando e identificando queste query problematiche, puoi apportare miglioramenti specifici che possono fare una differenza misurabile per le prestazioni del loro database. Ciò, a sua volta, consentirà una migliore scalabilità in futuro, nonché la soddisfazione complessiva del cliente, poiché app e siti saranno più reattivi.

MariaDB (e MySQL) forniscono diversi strumenti e tecniche per la profilazione delle query, che tratteremo in questo articolo. Una volta identificate le query lente , il passo successivo sarà quello di ottimizzarle. Questo processo include l'identificazione della causa principale del problema e la modifica della struttura delle query per migliorarne l'efficienza.

Come profilare le query SQL (7 metodi)

Iniziamo suddividendo i diversi strumenti e tecniche disponibili per identificare query lente e inefficienti in modo da sapere dove concentrare gli sforzi di miglioramento:

1 – Il comandoEXPLAIN EXTENDED

Uno degli strumenti che possono essere utilizzati per analizzare le query SQL è il comandoEXPLAIN .

Eseguendo il comando EXPLAIN su una query, è possibile vedere come viene eseguita la query, inclusi gli indici utilizzati e il numero di righe esaminate.

EXPLAIN SELECT * FROM orders

JOIN customers ON orders.customer_id = customers.customer_id

WHERE customers.name = 'John Smith';

Quando esegui il comando EXPLAINsu una query, restituisce un set di risultati con diverse colonne, tra cui:

• id: l'identificatore univoco della query nel piano di esecuzione
• select_type: il tipo di query, ad esempio SIMPLE o SUBQUERY
• table: la tabella che viene interrogata
• type: il tipo di join utilizzato, ad esempio JOIN o INDEX
• possible_keys: gli indici che MariaDB o MySQL avrebbero potuto utilizzare per elaborare la query
• key: l'indice utilizzato da MariaDB o MySQL per elaborare la query
• key_len: la lunghezza della chiave utilizzata
• rows: il numero di righe che MariaDB o MySQL stimano verranno esaminate per la query

Extra: contiene informazioni aggiuntive sulla query, ad esempio se è stata eseguita una scansione completa della tabella o se è stata utilizzata una tabella temporanea.

Analizzando l'output del comandoEXPLAIN, in genere si è in grado di identificare potenziali colli di bottiglia delle prestazioni, come un'indicizzazione scadente, tipi di join non ottimali o un numero elevato di righe esaminate.

Ad esempio, se la colonna del tipo mostra "ALL" invece di "index", la query sta eseguendo una scansione completa della tabella, che quasi sicuramente si tradurrà in un rallentamento delle prestazioni. Se la colonna chiave è NULL, MySQL non utilizza alcun indice, che sarà anche lento. Se la colonna delle righe ha un valore elevato, significa che vengono esaminate molte righe, con conseguente ulteriore peggioramento delle prestazioni.

Preferiamo utilizzare la variazione EXPLAIN EXTENDED per contribuire a fornire ulteriori informazioni.

Nota: sebbene sia deprecato in MySQL, è ancora disponibile in MariaDB.

Utilizzando l'opzione EXTENDED, potrai visualizzare informazioni utili come il numero di righe esaminate, il numero di righe restituite, informazioni sul tipo di JOIN utilizzato, l'ordine delle tabelle scansionate, gli indici utilizzati e per quanto tempo la query ha richiesto di essere eseguita.

Ecco come appare l'utilizzo del comando EXPLAIN EXTENDED:

EXPLAIN EXTENDED SELECT * FROM your_table WHERE column_name = 'value';

In questo esempio, il comando EXPLAIN mostrerà un elenco di passaggi che il database eseguirà per eseguire la query, nonché un elenco delle risorse che utilizzerà.

Utilizzando questo comando, sarai più facilmente in grado di individuare i colli di bottiglia nella query, consentendoti di apportare tutte le modifiche necessarie che ti aiuteranno ad alleviarlo e ad accelerare le prestazioni della query.

Ad esempio, l'utilizzo del comando EXPLAIN EXTENDED può aiutare a identificare la necessità di aggiungere indici, ottimizzare le condizioni JOIN e limitare il numero totale di righe restituite dalla query.

Dovresti anche assicurarti di aver disabilitato la memorizzazione nella cache delle query durante l'esecuzione di questi test e ottimizzazioni per assicurarti di ottenere risultati accurati. Per fare ciò, esegui prima questo comando quando connetti il ​​tuo client.

SET SESSION query_cache_type=0;

Dopo aver apportato queste modifiche alla tua query, verifica nuovamente le sue prestazioni per identificare l'eventuale miglioramento ottenuto. Ricorda che, come con qualsiasi profilatura e ottimizzazione di una query, il processo è iterativo: aspettati di utilizzare il comando EXPLAIN EXTENDED, seguito da un test delle prestazioni, più volte.

2 – Il comandoEXPLAIN ANALYZE

Questo comando viene utilizzato per analizzare il piano di esecuzione di una query e restituire le metriche delle prestazioni, ad esempio il tempo effettivo impiegato dalla query per l'esecuzione e il numero di righe effettivamente esaminate. Analizzando i risultati del comando EXPLAIN ANALYZE, è possibile identificare eventuali colli di bottiglia nell'esecuzione della query, come la mancanza di indici o un numero elevato di righe da esaminare.

3 – Il registro delle query lente

Questa è una funzionalità integrata in MariaDB (e MySQL) che registra tutte le query che richiedono più di un certo periodo di tempo per essere eseguite. Il registro delle query lente può essere configurato per registrare le query che impiegano più tempo di una soglia specifica, ad esempio un secondo.

In Servebolt, il registro delle query lente registra tutte le query che impiegano più di 1 secondo per essere eseguite. Questo perché la maggior parte delle query dovrebbe essere eseguita in frazioni di secondo. Nel contesto di un'applicazione Web, come un sito che esegue WordPress, il caricamento di una singola pagina richiede tra 10 e 100 query di database, che devono essere tutte eseguite in sequenza prima che la pagina possa essere compilata in HTML e restituita all'utente.

L'attuale configurazione di Servebolt Cloud mantiene i log delle query lenti su un server di log globale. In caso di necessità, puoi semplicemente metterti in contatto con il nostro team di supporto e filtreremo il file per i registri pertinenti e ti forniremo l'output.

Nei tuoi ambienti, puoi abilitare il log delle query lente aggiungendo le seguenti righe al tuo file di configurazione MariaDB o MySQL (my.cnf o my.ini):

log_slow_queries = /path/to/slow.log

long_query_time = 1

4 – Piano di spiegazione visiva

Un piano di spiegazione visiva fornisce una rappresentazione grafica dell'output del comando EXPLAIN, semplificando la comprensione dell'esecuzione di una query e il rilevamento di eventuali problemi di prestazioni.

Nota: i piani Visual Explain sono utili quando sei nel processo di sviluppo di applicazioni web.

Invece dell'output di testo semplice, visualizza l'esecuzione della query in una struttura ad albero , con ogni nodo che rappresenta una tabella, un indice o un'operazione e le connessioni tra di essi rappresentano l'ordine delle operazioni.

Diversi strumenti, come MySQL Workbench e EXPLAIN Analyzer, possono generare piani di spiegazione visivi e offrire un'interfaccia interattiva per navigare nel piano di esecuzione ed esaminare ogni operazione in dettaglio.

Ad esempio, in MySQL Workbench, generare un piano di spiegazione visiva è semplice come eseguire la query e fare clic sul pulsante "Explain Plan " nella scheda dei risultati.Presenta una rappresentazione grafica del piano di esecuzione della query, insieme a informazioni dettagliate su ciascuna operazione. Ciò consente di identificare eventuali problemi di prestazioni e quindi ottimizzare la query secondo necessità.

5 – Il sintonizzatore MySQL

MySQL Tuner è uno script che controlla le prestazioni e la configurazione di un server di database e fornisce raccomandazioni per il miglioramento. Fornisce un riepilogo dello stato corrente del server, incluse informazioni come il numero totale di query, il numero di query lente e l'utilizzo corrente del pool di buffer.

Può anche essere utilizzato per controllare varie altre impostazioni, come la versione del database, il motore di archiviazione in uso e la configurazione della cache delle query e fornisce suggerimenti per l'ottimizzazione di queste impostazioni in base al carico di lavoro corrente.

Una delle principali differenze con altri strumenti è che si tratta di uno strumento da riga di comando che può essere eseguito sul server stesso o in remoto, semplificando l'automazione del processo di monitoraggio e ottimizzazione delle prestazioni del database.

Nota: se la tua applicazione web (e database) è già ospitata nel Servebolt Cloud, questo è qualcosa in cui il nostro team è specializzato ed è in grado di fare meglio di qualsiasi consiglio che uno strumento sarebbe in grado di fornire.

6 – Profilatori di query

Esistono query profiler di terze parti che possono essere utilizzati per profilare le query SQL, come MariaDB Enterprise Query Analyzer , Dataedo e Percona Toolkit . I query profiler di terze parti possono fornire caratteristiche e funzionalità aggiuntive rispetto agli strumenti integrati disponibili in MariaDB (o MySQL).

Nota: i Query Profiler sono utili durante lo sviluppo di applicazioni web.

Ad esempio, possono offrire informazioni più dettagliate sulle prestazioni delle query, come i tempi di esecuzione e i tempi di attesa del blocco, e possono fornire la visualizzazione dei dati in modi che non sono possibili con gli strumenti integrati.

Se gli strumenti integrati sono sufficienti per le tue esigenze, non è necessario utilizzare query profiler di terze parti. Tuttavia, se hai bisogno di informazioni più dettagliate o funzionalità avanzate, potrebbe valere la pena considerare un profiler di terze parti.

7 – Profilazione con strumenti di monitoraggio

Esistono anche numerosi strumenti di monitoraggio, come Prometheus, Grafana e Nagios, che possono essere utilizzati per profilare le query e monitorare le prestazioni dei database.

Prometheus è un efficiente sistema di monitoraggio in grado di raccogliere, archiviare ed eseguire query sui dati delle metriche, consentendoti di ottenere preziose informazioni in tempo reale.Si integra con MariaDB (e MySQL) per archiviare le metriche raccolte e viene fornito con Grafana per una visualizzazione efficace.

Grafana è un potente strumento di analisi open source che può essere utilizzato per monitorare e visualizzare i dati raccolti da Prometheus.L'impostazione di dashboard e avvisi personalizzati ti consente di tenere d'occhio le prestazioni del tuo database in tempo reale.

Nagios ti aiuta a tenere d'occhio lo stato di salute del tuo database in ogni momento.Può essere impostato per monitorare risorse chiave come CPU, RAM e spazio su disco, tenendo traccia anche di altri servizi e dispositivi di rete. Poiché è altamente configurabile, è un ottimo strumento per il monitoraggio proattivo delle query del database.

Con l'aiuto di questi strumenti di monitoraggio del server, puoi tenere traccia dei problemi di prestazioni e agire rapidamente, assicurandoti che il tuo server di database funzioni senza problemi.

Tecniche comuni di ottimizzazione delle query

Esistono diverse tecniche di ottimizzazione delle query comuni che possono essere utilizzate per migliorare le prestazioni delle query SQL:

1 – Indicizzazione

Gli indici sono un modo per velocizzare le query, in particolare quelle che utilizzano filtri(WHERE).L'utilizzo degli indici produce strutture di dati nel motore di database (MariaDB o MySQL) al di fuori di tabelle specifiche e punta ai dati che stai tentando di interrogare. Non entreremo troppo nei dettagli in questo post poiché l'utilizzo degli indici per migliorare le query del database merita un articolo a sé stante, qualcosa che intendiamo trattare in futuro.

Ad esempio, considera una tabella di grandi dimensioni chiamata "ordini" che contiene milioni di righe di dati, incluse informazioni come l'ID ordine, l'ID cliente e la data dell'ordine. Se viene eseguita una query per recuperare tutti gli ordini effettuati da un cliente specifico senza un indice sulla colonna ID cliente, MariaDB dovrebbe scansionare l'intera tabella per individuare i dati rilevanti. Ciò potrebbe richiedere molto tempo e risorse, soprattutto per i tavoli di grandi dimensioni.

In generale, ogni volta che sei sicuro di eseguire ripetutamente una query specifica e di leggere le prestazioni, la creazione di un indice (o più di uno) può essere l'approccio giusto per velocizzare tale query.

Nel contesto di WordPress, questo è molto comune. Molti plug-in sono creati da sviluppatori che (per comodità) utilizzano tabelle generiche e condivise senza utilizzare indici. Di conseguenza, è anche un'area in cui si registrano spesso miglioramenti delle prestazioni molto significativi.

Per visualizzare gli indici esistenti su una determinata tabella,

Puoi visualizzare tutti gli indici esistenti su una tabella specifica utilizzando SHOW INDEX FROM – come nell'esempio seguente per la tabella wp_postmeta:

MariaDB [db_name] > SHOW INDEX FROM wp_postmeta;

In uno scenario, abbiamo recentemente creato due indici per una tabella wp_postmeta:sb_postid_metakey e sb_postid_metakey_metaval.

Questi indici sono stati aggiunti in base all'osservazione delle query più lente e alla scoperta che erano tutte relativamente simili per la caratteristica di essere istruzioni SELECT che filtrano utilizzando WHERE oltre a molte condizioni di confronto (AND/OR). Dopo aver visto questo, ho rivisto gli indici correnti per la tabella utilizzata e ho eseguitoEXPLAIN EXTENDED sulla query per convalidare ulteriormente il mio approccio.

La query funzionava principalmente e utilizzava la tabella wp_postmeta utilizzandoJOIN.In base all'ordine in cui ciò avveniva, l'aggiunta di questi indici avrebbe consentito a MariaDB (o MySQL) di ottenere la sua risposta dagli indici invece di scansionare l'intera tabella con tutte le sue righe.

CREATE INDEX sb_postid_metakey ON wp_postmeta (post_id, meta_key);

CREATE INDEX sb_postid_metakey_metaval ON wp_postmeta (post_id, meta_key, meta_value);

Questa è una combinazione di "capire le cose" utilizzando gli strumenti che hai a disposizione (come descritto sopra), così come la conoscenza dei tipi di dati e dei contenuti del database. Questo non sempre funziona; anche quando lo fa, non sempre si traduce in un miglioramento delle prestazioni del 500%. Avere un indice enorme può finire per essere più lento della scansione di tutte le righe, quindi le query devono essere testate prima e dopo aver applicato gli indici per essere sicuri.

Nota: quando tenti di testare le velocità dell'indice, ti consigliamo di disabilitare la memorizzazione nella cache delle query per la sessione, utilizzando:

SET SESSION query_cache_type=0;

In questo caso, prima di utilizzare gli indici, la query impiegava 10,437 secondi per essere eseguita. E dopo aver creato i due indici, la stessa query ha richiesto [# di secondi].

2 – Riduzione dell'accesso ai dati

Ridurre l'accesso ai dati , ovvero ridurre al minimo il numero di righe e colonne a cui accedere per eseguire una query.Ciò può essere ottenuto filtrando i dati recuperati dalla query, utilizzando indici e partizionando tabelle di grandi dimensioni. Sebbene non sia qualcosa di cui la maggior parte delle persone avrà bisogno (o sarà in grado) di farlo, è un punto essenziale da tenere a mente quando si progettano query di database da zero.

Ad esempio, se una query di database sta cercando dati su un utente per scopi di accesso, la query dovrebbe essere LIMIT 1, poiché chiaramente non dovrebbero mai essere richiesti più di un dato utente.

Nota: questo si riferisce più alla progettazione del database che all'ottimizzazione.Sebbene sia importante per mantenere le prestazioni, questo sforzo è più rilevante per gli sviluppatori di plug-in (nel contesto di WordPress) che per la maggior parte degli utenti finali.

Ricorda che prima di testare le velocità dopo aver apportato modifiche all'accesso ai dati, assicurati di aver disabilitato la memorizzazione nella cache delle query eseguendo il seguente comando:

SET SESSION query_cache_type=0;

3 – Utilizzo del partizionamento dei dati

Suddividendo i dati in blocchi più piccoli, i database diventano più efficienti e richiedono meno tempo per la gestione. Questa strategia può aiutare a ridurre la quantità di tempo dedicata ai processi di manutenzione come backup e aggiornamenti, oltre a limitare la quantità di dati che devono essere gestiti. Nel complesso aiuta a migliorare le prestazioni e ottimizzare l'utilizzo delle risorse.

Per suddividere i dati in un database, puoi seguire questi passaggi:

1. Quando selezioni una tabella da partizionare, assicurati di sceglierne una che contenga una grande quantità di dati e trarrebbe vantaggio dalla divisione. Ciò contribuirà a ottimizzare il sistema e migliorare le prestazioni delle query.
2. La selezione del metodo di partizionamento corretto per il database è fondamentale. Puoi scegliere tra intervallo, elenco, hash o partizionamento chiave, a seconda della struttura dei tuoi dati e delle query che intendi eseguire. Assicurati di scegliere quello più adatto alle tue esigenze per prestazioni e risultati ottimizzati.
   
   1. Il partizionamento per intervalli è la scelta ideale quando si dispone di dati che possono essere suddivisi in determinati intervalli.Ad esempio, se hai una tabella con dati per più anni, puoi creare una partizione di intervallo per organizzarla meglio. Potrebbe basarsi sulla data o sul valore numerico della colonna in questione.
   2. Il partizionamento dell'elenco è una tecnica efficiente per gestire i dati che possono essere facilmente segregati in vari gruppi secondo un particolare parametro.Ad esempio, hai una tabella con le informazioni sui dipendenti classificate per dipartimento; ciò richiede l'uso del partizionamento delle liste.
   3. Il partizionamento hash è una strategia efficace per disporre i dati in cluster di dimensioni uguali in base al valore hash di una colonna specifica.Ciò consente una distribuzione uniforme dei dati su più partizioni, rendendolo un'ottima scelta per distribuire i dati in modo efficiente.
   4. Il partizionamento delle chiavi è simile al partizionamento hash, ma la differenza principale è che utilizza un valore di colonna specifico come base per dividere i dati in gruppi diversi.Questo lo rende una scelta ideale per set di dati che possono essere suddivisi in gruppi separati basati su un identificatore univoco o una chiave naturale.
3. Creando una tabella partizionata, puoi dividere efficacemente la tabella originale in tabelle più piccole. Ciò si ottiene aggiungendo una clausola di partizionamento nell'istruzione CREATE TABLE, in cui si specificano il metodo e le condizioni desiderati per la segmentazione. Ciò può aiutare a migliorare le prestazioni delle query e anche a rendere più efficiente la gestione dei dati.
4. È possibile copiare rapidamente i dati dalla tabella originale a quella appena partizionata utilizzando l'istruzione INSERT INTO... SELECT. Questo popolerà facilmente la tua tabella partizionata con tutte le informazioni rilevanti.
5. Le applicazioni devono ora essere riconfigurate per sfruttare la tabella partizionata. Questo sostituirà la tabella originale e renderà le tue applicazioni più efficienti.
6. Prima di eseguire qualsiasi test per valutare il potenziale miglioramento delle prestazioni, sarà essenziale disabilitare prima la cache delle query eseguendo il comando: SET SESSION query_cache_type=0;
7. Per assicurarti che la tua tabella partizionata funzioni senza problemi, è importante tenere d'occhio le sue prestazioni. In caso di problemi, potrebbe essere utile modificare le condizioni di partizionamento o passare a un altro metodo. Monitorare regolarmente le tue partizioni ti aiuterà a massimizzare il loro potenziale.

Nota importante sugli aggiornamenti degli script e sulle tabelle partizionate

Mentre il partizionamento dei database può fare una differenza positiva in termini di efficienza, è importante tenere presente i potenziali problemi causati dall'esecuzione di script di aggiornamento per modificare lo schema del database. È essenziale che le tabelle partizionate vengano prese in considerazione durante la creazione di script per questi aggiornamenti. Se le tabelle partizionate non vengono prese in considerazione negli script di aggiornamento, potrebbero esserci potenziali problemi che quasi sicuramente causeranno un malfunzionamento del sito.

Ad esempio, se viene creato uno script per aggiungere una nuova colonna a una tabella partizionata, potrebbe alterare solo una partizione, creando incoerenze e problemi all'interno dei dati. Allo stesso modo, se viene creato uno script di aggiornamento per aggiungere un indice a una tabella partizionata, può generare l'indice solo su una partizione, con prestazioni più lente e risultati incoerenti.

Per evitare tali problemi, gli script di aggiornamento devono essere progettati per considerare le tabelle partizionate. Ciò potrebbe comportare l'esecuzione dello script su ciascuna partizione individualmente o la revisione degli script in modo che funzionino con le tabelle partizionate. È inoltre importante condurre test approfonditi per garantire che il processo di aggiornamento non generi problemi imprevisti o perdite di dati.

4 – Redis

Per i clienti Servebolt, Redis è un componente aggiuntivo (a pagamento) che può aiutare con l'ottimizzazione delle query.

Redis (a volte noto come Remote Dictionary Server) è una soluzione open source che archivia i dati in memoria e può essere utilizzata per la memorizzazione nella cache, un database o persino come broker di messaggi. Può essere integrato con un database per migliorare le prestazioni, fungendo da efficiente intermediario tra l'applicazione e il database.

Funziona per migliorare le prestazioni e i tempi di risposta delle applicazioni riducendo il carico sul database. Questo viene fatto memorizzando i dati utilizzati di frequente in Redis anziché nel database per ogni richiesta, risparmiando così molto tempo.

Configurando correttamente il plug-in, Redis può essere utilizzato con un database per ottimizzare l'esecuzione delle query. Quando i dati richiesti non sono presenti in Redis, l'applicazione li recupererà dal database e li memorizzerà in Redis per un uso futuro. Questo rende il recupero dei dati molto più veloce ed efficiente.

Utilizzando questo approccio, l'applicazione può trarre vantaggio dal rapido accesso in memoria di Redis e anche archiviare e accedere ai dati dal database secondo necessità.

Ricorda che se stai implementando Redis per la prima volta, dovrai disabilitare la memorizzazione nella cache delle query prima di eseguire qualsiasi test delle prestazioni. Per fare ciò, usa il comando:

SET SESSION query_cache_type=0;

Conclusione

L'ecosistema MariaDB e MySQL dispone di un'ampia gamma di strumenti e metodi per facilitare la scoperta dei colli di bottiglia nelle esecuzioni delle query del database, consentendoti di migliorare le prestazioni delle tue applicazioni web.

È probabile che si verifichino rallentamenti per tutta la durata dell'esecuzione di qualsiasi applicazione. Cercare di evitarli è fantastico, ma alla fine devi sapere dove guardare quando inizi a diagnosticare problemi di prestazioni. A seconda delle dimensioni e della natura dei database in esecuzione, si tratta di un processo iterativo che richiede monitoraggio continuo, risoluzione dei problemi e miglioramenti continui per mantenere le prestazioni dei database a uno standard elevato.