Niedawno bawiłem się z pamięcią podręczną wyników… wiem… to nie jest nowa funkcja i była dostępna od jakiegoś czasu. Niestety, dotarcie do rzeczy, które myślę, może trochę potrwać.
W moim prostym teście miałem zapytanie, które wykazywało to zachowanie:
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 odczytów dysku, aby zwrócić 1 wiersz. Auć! Teraz przeprowadź to przez pamięć podręczną wyników i uzyskaj naprawdę ładne liczby.
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
Nadal zwrócił 1 wiersz, ale zero odczytów dysku, zero bloków prądu i zasadniczo zero czasu, który upłynął. Fajnie!
Pamięć podręczna wyników działa najlepiej, gdy zwraca kilka wierszy w tabelach, które nie zmieniają się często. Operacje DML na bazowych tabelach unieważnią wpis w pamięci podręcznej wyników, a praca będzie musiała zostać wykonana od nowa, zanim zostanie zapisana w pamięci podręcznej wyników.
Niedługo, kiedy będę miał okazję, zorientuję się, jaki wpływ mają zmienne wiązania na zapytania korzystające z pamięci podręcznej wyników.
