L'output di EXPLAIN PLAN è un output di debug dell'ottimizzatore di query di Oracle. Il COST è l'output finale dell'ottimizzatore basato sui costi (CBO), il cui scopo è selezionare quale dei molti diversi piani possibili dovrebbe essere utilizzato per eseguire la query. Il CBO calcola un costo relativo per ogni piano, quindi seleziona il piano con il costo più basso.
(Nota:in alcuni casi il CBO non ha abbastanza tempo per valutare ogni possibile piano; in questi casi si limita a scegliere il piano con il costo più basso trovato finora)
In generale, uno dei maggiori contributori a una query lenta è il numero di righe lette per soddisfare la query (blocchi, per essere più precisi), quindi il costo sarà basato in parte sul numero di righe dovranno essere lette le stime dell'ottimizzatore.
Ad esempio, supponiamo che tu abbia la seguente query:
SELECT emp_id FROM employees WHERE months_of_service = 6;
(I months_of_service colonna ha un vincolo NOT NULL su di essa e un normale indice su di essa.)
Ci sono due piani di base che l'ottimizzatore potrebbe scegliere qui:
- Piano 1:leggi tutte le righe della tabella "impiegati", per ciascuna verifica se il predicato è vero (
months_of_service=6). - Piano 2:leggi l'indice dove
months_of_service=6(questo si traduce in un insieme di ROWID), quindi accedi alla tabella in base ai ROWID restituiti.
Immaginiamo che la tabella "dipendenti" abbia 1.000.000 (1 milione) di righe. Immaginiamo inoltre che i valori per mesi_di_servizio siano compresi tra 1 e 12 e siano distribuiti in modo abbastanza uniforme per qualche motivo.
Il costo del Piano 1 , che prevede una SCANSIONE COMPLETA, sarà il costo della lettura di tutte le righe della tabella dipendenti, che è pari a circa 1.000.000; ma poiché Oracle sarà spesso in grado di leggere i blocchi utilizzando letture multiblocco, il costo effettivo sarà inferiore (a seconda di come è impostato il database), ad es. immaginiamo che il conteggio delle letture multiblocco sia 10 - il costo calcolato della scansione completa sarà 1.000.000 / 10; Costo complessivo =100.000.
Il costo del Piano 2 , che prevede un INDEX RANGE SCAN e una ricerca nella tabella da parte di ROWID, sarà il costo della scansione dell'indice, più il costo di accesso alla tabella da parte di ROWID. Non approfondirò il costo delle scansioni dell'intervallo di indici, ma immaginiamo che il costo della scansione dell'intervallo di indici sia 1 per riga; ci aspettiamo di trovare una corrispondenza in 1 caso su 12, quindi il costo della scansione dell'indice è 1.000.000 / 12 =83.333; più il costo di accesso alla tabella (supponiamo 1 blocco letto per accesso, non possiamo usare letture multiblocco qui) =83.333; Costo complessivo =166.666.
Come puoi vedere, il costo del Piano 1 (scansione completa) è INFERIORE al costo del Piano 2 (scansione dell'indice + accesso tramite rowid), il che significa che il CBO sceglierebbe la scansione COMPLETA.
Se le ipotesi fatte qui dall'ottimizzatore sono vere, in effetti il Piano 1 sarà preferibile e molto più efficiente del Piano 2, il che smentisce il mito secondo cui le scansioni COMPLETE sono "sempre pessime".
I risultati sarebbero molto diversi se l'obiettivo dell'ottimizzatore fosse FIRST_ROWS(n) invece di ALL_ROWS - nel qual caso l'ottimizzatore preferirebbe il Piano 2 perché spesso restituirà le prime righe più velocemente, a costo di essere meno efficiente per l'intera query .
