Outputtet af EXPLAIN PLAN er et fejlfindingsoutput fra Oracles forespørgselsoptimering. COST er det endelige output af Cost-based Optimizer (CBO), hvis formål er at vælge, hvilken af de mange forskellige mulige planer, der skal bruges til at køre forespørgslen. CBO'en beregner en relativ pris for hver plan og vælger derefter planen med den laveste pris.
(Bemærk:I nogle tilfælde har CBO'en ikke tid nok til at evaluere alle mulige planer; i disse tilfælde vælger den blot planen med de laveste omkostninger fundet indtil videre)
Generelt er en af de største bidragydere til en langsom forespørgsel antallet af læste rækker for at servicere forespørgslen (blokke, for at være mere præcis), så prisen vil delvis være baseret på på antallet af rækker, skal optimeringsestimaterne læses.
Lad os f.eks. sige, at du har følgende forespørgsel:
SELECT emp_id FROM employees WHERE months_of_service = 6;
(months_of_service kolonne har en NOT NULL-begrænsning på sig og et almindeligt indeks på sig.)
Der er to grundlæggende planer, som optimeringsværktøjet kan vælge her:
- Plan 1:Læs alle rækkerne fra tabellen "medarbejdere", tjek for hver række, om prædikatet er sandt (
months_of_service=6). - Plan 2:Læs indekset hvor
months_of_service=6(dette resulterer i et sæt ROWID'er), og få derefter adgang til tabellen baseret på de returnerede ROWID'er.
Lad os forestille os, at tabellen "medarbejdere" har 1.000.000 (1 million) rækker. Lad os yderligere forestille os, at værdierne for months_of_service varierer fra 1 til 12 og er nogenlunde jævnt fordelt af en eller anden grund.
Prisen for Plan 1 , som involverer en FULD SCANNING, vil være omkostningerne ved at læse alle rækkerne i medarbejdertabellen, hvilket er cirka lig med 1.000.000; men da Oracle ofte vil være i stand til at læse blokkene ved hjælp af multi-blok læsninger, vil de faktiske omkostninger være lavere (afhængig af hvordan din database er sat op) - f.eks. lad os forestille os, at multi-blok læsetællingen er 10 - den beregnede pris for den fulde scanning vil være 1.000.000 / 10; Samlet pris =100.000.
Prisen for Plan 2 , som involverer en INDEX RANGE SCAN og et tabelopslag af ROWID, vil være omkostningerne ved at scanne indekset plus omkostningerne ved at få adgang til tabellen af ROWID. Jeg vil ikke gå ind på, hvordan indeksområdescanninger er prissat, men lad os forestille os, at prisen på indeksområdescanningen er 1 pr. række; vi forventer at finde et match i 1 ud af 12 tilfælde, så prisen for indeksscanningen er 1.000.000 / 12 =83.333; plus omkostningerne ved at få adgang til tabellen (antag 1 blok læsning pr. adgang, vi kan ikke bruge multi-blok læsninger her) =83.333; Samlet pris =166.666.
Som du kan se, er prisen på plan 1 (fuld scanning) MINDRE end prisen på plan 2 (indeksscanning + adgang via rowid) - hvilket betyder, at CBO'en ville vælge den fulde scanning.
Hvis de antagelser, som optimeres her, er sande, så vil i virkeligheden plan 1 være at foretrække og meget mere effektiv end plan 2 - hvilket afkræfter myten om, at FULDE scanninger er "altid dårlige".
Resultaterne ville være helt anderledes, hvis optimeringsmålet var FIRST_ROWS(n) i stedet for ALL_ROWS - i hvilket tilfælde optimeringsværktøjet ville favorisere plan 2, fordi det ofte vil returnere de første par rækker hurtigere, på bekostning af at være mindre effektiv for hele forespørgslen .