Hôm trước tôi đã chơi với Result Cache… Tôi biết… đây không phải là một tính năng mới và đã có sẵn trong một thời gian. Thật không may, có thể mất một lúc để đạt được những điều tôi đoán.
Trong thử nghiệm đơn giản của mình, tôi có một truy vấn thể hiện hành vi này:
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 lần đọc đĩa để trả về 1 hàng. Ầm ầm! Bây giờ chạy điều này thông qua Bộ đệm kết quả và nhận được một số con số thực sự đẹp. 🙂
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
Vẫn còn 1 hàng được trả về nhưng không có lần đọc đĩa nào, không có khối hiện tại và về cơ bản là không có thời gian trôi qua. Tốt!
Bộ đệm kết quả hoạt động tốt nhất khi trả về một số hàng trên bảng không thay đổi thường xuyên. Các thao tác DML trên các bảng bên dưới sẽ làm mất hiệu lực mục nhập Bộ đệm kết quả và công việc sẽ cần được thực hiện lại trước khi nó được lưu trữ trong Bộ đệm kết quả.
Đôi khi, khi có cơ hội, tôi sẽ tìm hiểu tác động của các biến liên kết đối với các truy vấn sử dụng Bộ nhớ cache kết quả.
