Онзи ден си играех с кеша на резултатите… знам… това не е нова функция и е налична от известно време. За съжаление, може да отнеме известно време, за да стигнем до нещата, които предполагам.
В моя прост тест имах заявка, която показа това поведение:
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 четения на диска за връщане на 1 ред. Оу! Сега прокарайте това през кеша на резултатите и вземете някои наистина хубави числа. 🙂
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
Все пак се върна 1 ред, но нула четене на диск, нулеви текущи блокове и основно нулево изминало време. Хубаво!
Кешът на резултатите работи най-добре, когато връща няколко реда в таблици, които не се променят често. DML операциите върху основните таблици ще анулират записа в кеша на резултатите и работата ще трябва да бъде извършена наново, преди да бъде съхранена в кеша на резултатите.
Някога скоро, когато имам възможност, ще разбера влиянието на променливите за свързване върху заявки, които използват кеша на резултатите.
