Presumo anche che tu stia usando Oracle. E ti consiglio anche di controllare la pagina web spiega il piano, per cominciare. C'è molto da ottimizzare, ma si può imparare.
Seguono alcuni suggerimenti:
In primo luogo, quando qualcuno ti incarica di ottimizzare, è quasi sempre alla ricerca di prestazioni accettabili piuttosto che prestazioni massime. Se puoi ridurre il tempo di esecuzione di una query da 3 minuti a 3 secondi, non preoccuparti di ridurla a 2 secondi, finché non ti viene richiesto.
In secondo luogo, fai un rapido controllo per assicurarti che le query che stai ottimizzando siano logicamente corrette. Sembra assurdo, ma non posso dirti quante volte mi è stato chiesto consiglio su una query a esecuzione lenta, solo per scoprire che a volte dava risposte sbagliate! E a quanto pare, il debug della query spesso si è rivelato anche per velocizzarla.
In particolare, cerca la frase "Unisci cartesiani" nel piano di spiegazione. Se lo vedi lì, è molto probabile che tu abbia trovato un join cartesiano non intenzionale. Il modello usuale per un join cartesiano non intenzionale è che la clausola FROM elenca le tabelle separate da virgole e le condizioni di join sono nella clausola WHERE. Tranne che manca una delle condizioni di join, quindi Oracle non ha altra scelta che eseguire un join cartesiano. Con tabelle di grandi dimensioni, questo è un disastro di prestazioni.
È possibile vedere un join cartesiano nel piano di spiegazione in cui la query è logicamente corretta, ma lo associo a versioni precedenti di Oracle.
Cerca anche l'indice composto inutilizzato. Se la prima colonna di un indice composto non viene utilizzata nella query, Oracle potrebbe utilizzare l'indice in modo inefficiente o non utilizzarlo affatto. Faccio un esempio:
La domanda era:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(Il DBMS non era Oracle, quindi la sintassi era diversa e ho dimenticato la sintassi originale).
Una rapida occhiata agli indici ha rivelato un indice sui clienti con le colonne (Paese, Stato, Codice postale) in quell'ordine. Ho cambiato la query in read
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
e ora ha funzionato in circa 6 secondi invece di circa 6 minuti, perché l'ottimizzatore è stato in grado di utilizzare l'indice con un buon vantaggio. Ho chiesto ai programmatori dell'applicazione perché avevano omesso il paese dai criteri, e questa è stata la loro risposta:sapevano che tutti gli indirizzi avevano il paese uguale a "USA", quindi hanno pensato di poter velocizzare la query tralasciando quel criterio!
Sfortunatamente, l'ottimizzazione del recupero del database non è proprio la stessa cosa che ridurre i microsecondi del tempo di elaborazione. Implica la comprensione della progettazione del database, in particolare gli indici, e almeno una panoramica di come l'ottimizzatore svolge il proprio lavoro.
In genere ottieni risultati migliori dall'ottimizzatore quando impari a collaborare con esso invece di cercare di superarlo in astuzia.
Buona fortuna per l'ottimizzazione!
