L'altro giorno stavo giocando con la Cache dei risultati... lo so... questa non è una nuova funzionalità ed è disponibile da un po'. Sfortunatamente, può volerci un po' per arrivare a cose che credo.
Nel mio semplice test, ho avuto una query che mostrava questo comportamento:
select
max(det.invoice_date)
from
invoices i
join
invoice_detail det
on i.dept_id=det.dept_id
call count cpu elapsed disk query current rows
------- ------ ------- -------- ---------- ---------- --------- ---------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 2.77 6.66 75521 75583 0 1
------- ------ ------- -------- ---------- ---------- ---------- ---------
total 4 2.77 6.67 75521 75583 0 1
75.000 letture del disco per restituire 1 riga. Ahia! Ora esegui questo attraverso la Cache dei risultati e ottieni dei numeri davvero carini. 🙂
select
/*+ result_cache */
max(det.invoice_date)
from
invoices i
join
invoice_detail det
on i.dept_id=det.dept_id
call count cpu elapsed disk query current rows
------- ------ ------ --------- ---------- ---------- ---------- ---------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 0 0 1
------- ------ ------ --------- ---------- ---------- ---------- ---------
total 4 0.00 0.00 0 0 0 1
Ancora 1 riga restituita ma zero letture del disco, zero blocchi correnti e praticamente zero tempo trascorso. Bello!
La cache dei risultati funziona meglio quando restituisce un numero limitato di righe su tabelle che non cambiano spesso. Le operazioni DML sulle tabelle sottostanti invalideranno la voce della Cache dei risultati e il lavoro dovrà essere eseguito di nuovo prima che venga archiviato nella Cache dei risultati.
Presto, quando ne avrò la possibilità, capirò l'impatto delle variabili di binding sulle query che utilizzano la Cache dei risultati.
