sql >> Databasteknik >  >> RDS >> Oracle

Förstå resultatet av Execute Explain Plan i Oracle SQL Developer

Utdata från EXPLAIN PLAN är en felsökningsutgång från Oracles frågeoptimerare. COST är slutresultatet av den kostnadsbaserade optimeraren (CBO), vars syfte är att välja vilken av de många olika möjliga planerna som ska användas för att köra frågan. CBO:n beräknar en relativ kostnad för varje plan och väljer sedan planen med den lägsta kostnaden.

(Obs:i vissa fall har CBO inte tillräckligt med tid för att utvärdera alla möjliga planer; i dessa fall väljer den bara planen med den lägsta kostnaden hittills)

I allmänhet är en av de största bidragsgivarna till en långsam fråga antalet rader som läses för att betjäna frågan (blockerar, för att vara mer exakt), så kostnaden kommer att baseras delvis på antalet rader kommer optimeringsuppskattningarna att behöva läsas.

Låt oss till exempel säga att du har följande fråga:

SELECT emp_id FROM employees WHERE months_of_service = 6;

(months_of_service kolumnen har en NOT NULL-begränsning och ett vanligt index på sig.)

Det finns två grundläggande planer som optimeraren kan välja här:

  • Plan 1:Läs alla rader från tabellen "anställda", kontrollera för varje rad om predikatet är sant (months_of_service=6 ).
  • Plan 2:Läs indexet där months_of_service=6 (detta resulterar i en uppsättning ROWIDs), öppna sedan tabellen baserat på returnerade ROWID.

Låt oss föreställa oss att tabellen "anställda" har 1 000 000 (1 miljon) rader. Låt oss vidare föreställa oss att värdena för months_of_service sträcker sig från 1 till 12 och är ganska jämnt fördelade av någon anledning.

Kostnaden för Plan 1 , som involverar en FULLSTÄNDIG SCANNING, kommer att vara kostnaden för att läsa alla rader i tabellen för anställda, vilket är ungefär lika med 1 000 000; men eftersom Oracle ofta kommer att kunna läsa blocken med hjälp av multi-block reads, blir den faktiska kostnaden lägre (beroende på hur din databas är inställd) - t.ex. låt oss föreställa oss att läsräkningen i flera block är 10 - den beräknade kostnaden för den fullständiga skanningen kommer att vara 1 000 000 / 10; Total kostnad =100 000.

Kostnaden för Plan 2 , som involverar en INDEX RANGE SCAN och en tabellsökning av ROWID, kommer att vara kostnaden för att skanna indexet, plus kostnaden för att komma åt tabellen med ROWID. Jag kommer inte att gå in på hur indexintervallsskanningar kostar men låt oss föreställa oss att kostnaden för indexintervallskanningen är 1 per rad; vi förväntar oss att hitta en matchning i 1 av 12 fall, så kostnaden för indexskanningen är 1 000 000 / 12 =83 333; plus kostnaden för åtkomst till tabellen (anta 1 block läsning per åtkomst, vi kan inte använda multiblock läsningar här) =83 333; Total kostnad =166 666.

Som du kan se är kostnaden för Plan 1 (fullständig skanning) LINDRE än kostnaden för Plan 2 (indexskanning + åtkomst av rowid) - vilket innebär att CBO skulle välja FULLSTÄNDIG genomsökning.

Om antagandena som görs här av optimeraren är sanna, så kommer i själva verket Plan 1 att vara att föredra och mycket effektivare än Plan 2 - vilket motbevisar myten att FULLSTÄNDIGA skanningar är "alltid dåliga".

Resultaten skulle bli helt annorlunda om optimerarmålet var FIRST_ROWS(n) istället för ALL_ROWS - i så fall skulle optimeraren gynna plan 2 eftersom den ofta returnerar de första raderna snabbare, till priset av att den är mindre effektiv för hela frågan .



  1. Har problem med att matcha rader i databasen med PDO

  2. Hur man krymper/rensar ibdata1-fil i MySQL

  3. Hur man filtrerar frågeresultat i PostgreSQL

  4. Räkna rekord för varje månad under ett år