sql >> Databasteknik >  >> RDS >> Oracle

Förklara Planera kostnadssmärta

Tidigare idag arbetade jag med en utvecklare på en fråga som hade dålig prestanda. Denna fråga var stor och komplex, och från början såg det ut som en skrämmande ansträngning att ta reda på var prestandaproblemet ligger. Med Explain Plan kan vi ibland använda kostnaden för att minska prestationssmärtpunkten för en stor, komplex fråga.

När vi tittar på en förklaringsplan för denna fråga kan vi se att dess totala kostnad är ganska hög.

När vi tittar på detaljerna kan vi se att FULL table scan (FTS) på DETAIL_RECORD-tabellen har en hög kostnad på 51018. Lägg märke till hur den höga kostnaden för FTS sprider sig i planen. Alla operationer ovanför denna FTS har en hög kostnad på grund av den höga kostnaden för denna enkelbordsåtkomst. Åtkomst till tabellen CIMS_POLICIES_TO_PROCESS har en relativt låg kostnad, men HASH JOIN-operationen får sin höga kostnad endast på grund av den höga kostnaden för att komma åt tabellen DETAIL_RECORD.

Den totala kostnaden är bara lite mer än kostnaden för att komma åt detta bord. Det är tydligt att FTS i den här tabellen är den största bidragsgivaren till smärtpunkten för den här frågan som analyseras.

Genom att titta på Explain Plan-kostnaderna på detta sätt kunde vi mycket snabbt fokusera på det ena området i en mycket komplex fråga som orsakar störst prestationsbesvär. Utan kostnadsanalysen som gjorts här skulle det ha varit mycket jobb att avgöra vilken del av frågan nedan som orsakar problem.


  1. Användningsfall för MariaDB och Docker, del 1

  2. Hur man returnerar element från en JSON-array i MariaDB

  3. Salesforce SOQL från Apache OpenOffice

  4. Python/postgres/psycopg2:få ID för raden som precis har infogats