Jeg legede med Result Cache den anden dag ... jeg ved det ... dette er ikke en ny funktion og har været tilgængelig i et stykke tid. Desværre kan det tage et stykke tid at komme til ting, tror jeg.
I min simple test havde jeg en forespørgsel, der viste denne adfærd:
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 disklæsninger for at returnere 1 række. Av! Kør nu dette gennem resultatcachen og få nogle rigtig flotte tal. 🙂
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
Stadig 1 række returnerede, men nul diskaflæsninger, nul strømblokke og stort set nul forløbet tid. Dejligt!
Resultatcachen fungerer bedst, når der returneres et par antal rækker på tabeller, der ikke ændres ofte. DML-handlinger på de underliggende tabeller vil ugyldiggøre resultatcachen, og arbejdet skal udføres på ny, før det gemmes i resultatcachen.
En gang om lidt, når jeg får en chance, vil jeg finde ud af virkningen af bindevariabler på forespørgsler, der bruger resultatcachen.