Ich habe neulich mit dem Ergebnis-Cache herumgespielt … ich weiß … das ist keine neue Funktion und ist schon eine Weile verfügbar. Leider kann es eine Weile dauern, bis ich zu den Dingen komme, denke ich.
In meinem einfachen Test hatte ich eine Abfrage, die dieses Verhalten zeigte:
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 Festplattenlesevorgänge, um 1 Zeile zurückzugeben. Autsch! Führen Sie dies nun durch den Ergebniscache und erhalten Sie einige wirklich schöne Zahlen. 🙂
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
Immer noch 1 Zeile zurückgegeben, aber null Festplattenlesevorgänge, null aktuelle Blöcke und im Grunde null verstrichene Zeit. Schön!
Der Ergebnis-Cache funktioniert am besten, wenn er einige Zeilen in Tabellen zurückgibt, die sich nicht oft ändern. DML-Operationen auf den zugrunde liegenden Tabellen machen den Ergebnis-Cache-Eintrag ungültig und die Arbeit muss erneut durchgeführt werden, bevor sie im Ergebnis-Cache gespeichert wird.
Wenn ich bald Gelegenheit dazu habe, werde ich die Auswirkungen von Bind-Variablen auf Abfragen herausfinden, die den Ergebnis-Cache verwenden.
