Estuve jugando con Result Cache el otro día... Lo sé... esta no es una característica nueva y ha estado disponible por un tiempo. Desafortunadamente, supongo que puede llevar un tiempo llegar a las cosas.
En mi prueba simple, tuve una consulta que mostraba este comportamiento:
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 lecturas de disco para devolver 1 fila. ¡Ay! Ahora ejecute esto a través de la memoria caché de resultados y obtenga algunos números realmente buenos. 🙂
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
Todavía se devolvió 1 fila pero cero lecturas de disco, cero bloques actuales y básicamente cero tiempo transcurrido. ¡Genial!
La caché de resultados funciona mejor cuando devuelve unas pocas filas en tablas que no cambian con frecuencia. Las operaciones DML en las tablas subyacentes invalidarán la entrada de la memoria caché de resultados y el trabajo deberá realizarse de nuevo antes de que se almacene en la memoria caché de resultados.
Dentro de poco, cuando tenga la oportunidad, averiguaré el impacto de las variables de vinculación en las consultas que utilizan la caché de resultados.
