Je jouais avec le cache de résultats l'autre jour… je sais… ce n'est pas une nouvelle fonctionnalité et elle est disponible depuis un certain temps. Malheureusement, cela peut prendre un certain temps pour arriver aux choses, je suppose.
Dans mon test simple, j'avais une requête qui présentait ce comportement :
sélectionner
max(det.invoice_date)
de
factures i
rejoindre
facture_détail det
sur i.dept_id=det.dept_id
call count cpu disk query current rows------- ------ ------- -------- ---------- --------- - --------- ---------Analyse 1 0.00 0.00 0 0 0 0Exécuter 1 0,00 0,00 0 0 0 0Récupérer 2 2,77 6,66 75521 75583 0 1------- ------ ------- -------- ---------- --------- - ---------- ---------total 4 2,77 6,67 75521 75583 0 175 000 lectures de disque pour renvoyer 1 ligne. Aie! Maintenant, exécutez-le dans le cache de résultats et obtenez de très bons chiffres. 🙂
sélectionner/*+ result_cache */max(det.invoice_date)defactures irejoindrefacture_détail detsur i.dept_id=det.dept_idappel nombre cpu écoulé disque requête lignes actuelles------- ------ ------ --------- ---------- --------- - ---------- ---------Analyse 1 0.00 0.00 0 0 0 0Exécuter 1 0,00 0,00 0 0 0 0Récupérer 2 0,00 0,00 0 0 0 1------- ------ ------ --------- ---------- --------- - ---------- ---------total 4 0,00 0,00 0 0 0 1
Toujours 1 ligne renvoyée mais zéro lecture de disque, zéro bloc actuel et pratiquement aucun temps écoulé. Génial !
Le cache de résultats fonctionne mieux lorsqu'il renvoie un petit nombre de lignes sur des tables qui ne changent pas souvent. Les opérations DML sur les tables sous-jacentes invalideront l'entrée du cache de résultats et le travail devra être effectué à nouveau avant d'être stocké dans le cache de résultats.
Bientôt, quand j'en aurai l'occasion, je vais comprendre l'impact des variables de liaison sur les requêtes qui utilisent le cache de résultats.
