先日、結果キャッシュをいじっていました…わかっています…これは新しい機能ではなく、しばらくの間利用可能でした。残念ながら、私が推測するものに到達するまでには時間がかかる場合があります。
私の簡単なテストでは、この動作を示すクエリがありました：
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操作は、結果キャッシュエントリを無効にするため、結果キャッシュに保存する前に、作業を新たに実行する必要があります。
近いうちに、機会があれば、結果キャッシュを使用するクエリに対するバインド変数の影響を把握する予定です。