Jag lekte med Result Cache häromdagen ... jag vet ... det här är inte en ny funktion och har varit tillgänglig ett tag. Tyvärr kan det ta ett tag att komma till saker antar jag.
I mitt enkla test hade jag en fråga som visade detta beteende:
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äsningar för att returnera 1 rad. aj! Kör nu detta genom resultatcachen och få några riktigt fina siffror. 🙂
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
Fortfarande 1 rad returnerade men noll skivavläsningar, noll strömblock och i princip noll förfluten tid. Trevligt!
Resultatcachen fungerar bäst när du returnerar ett fåtal rader i tabeller som inte ändras ofta. DML-operationer på de underliggande tabellerna kommer att ogiltigförklara posten Result Cache och arbetet kommer att behöva utföras på nytt innan det kommer att lagras i Result Cache.
Någon gång snart, när jag får en chans, ska jag ta reda på effekten av bindningsvariabler på frågor som använder resultatcachen.