sql >> Databáze >  >> RDS >> Oracle

Pochopení výsledků Execute Explain Plan v Oracle SQL Developer

Výstupem EXPLAIN PLAN je výstup ladění z optimalizátoru dotazů Oracle. COST je konečným výstupem optimalizátoru založeného na nákladech (CBO), jehož účelem je vybrat, který z mnoha různých možných plánů by měl být použit ke spuštění dotazu. CBO vypočítá relativní náklady pro každý plán a poté vybere plán s nejnižšími náklady.

(Poznámka:v některých případech CBO nemá dostatek času na vyhodnocení všech možných plánů; v těchto případech pouze vybere plán s nejnižšími dosud zjištěnými náklady)

Obecně platí, že jedním z největších přispěvatelů k pomalému dotazu je počet přečtených řádků pro obsluhu dotazu (přesněji bloků), takže náklady budou založeny částečně na počtu řádků, které bude potřeba přečíst odhady optimalizátoru.

Řekněme například, že máte následující dotaz:

SELECT emp_id FROM employees WHERE months_of_service = 6;

(months_of_service sloupec má omezení NOT NULL a obsahuje obyčejný index.)

Zde jsou dva základní plány, které může optimalizátor zvolit:

  • Plán 1:Přečtěte si všechny řádky z tabulky „zaměstnanci“, u každého zkontrolujte, zda je predikát pravdivý (months_of_service=6 ).
  • Plán 2:Přečtěte si index, kde months_of_service=6 (to vede k sadě ROWID), poté přistupte k tabulce na základě vrácených ROWID.

Představme si, že tabulka „zaměstnanců“ má 1 000 000 (1 milion) řádků. Představme si dále, že hodnoty pro months_of_service se pohybují od 1 do 12 a jsou z nějakého důvodu poměrně rovnoměrně rozloženy.

Cena plánu 1 , která zahrnuje ÚPLNÉ SKENOVÁNÍ, budou náklady na přečtení všech řádků v tabulce zaměstnanců, což je přibližně 1 000 000; ale protože Oracle bude často schopen číst bloky pomocí čtení více bloků, skutečné náklady budou nižší (v závislosti na tom, jak je vaše databáze nastavena) - např. představme si, že počet čtení z více bloků je 10 – vypočítaná cena úplného skenování bude 1 000 000 / 10; Celkové náklady =100 000.

Cena Plánu 2 , která zahrnuje INDEX RANGE SCAN a vyhledávání tabulky pomocí ROWID, budou náklady na skenování indexu plus náklady na přístup k tabulce pomocí ROWID. Nebudu zabíhat do toho, jak se cení prohledávání rozsahu indexu, ale představme si, že cena skenování rozsahu indexu je 1 na řádek; očekáváme, že najdeme shodu v 1 z 12 případů, takže náklady na skenování indexu jsou 1 000 000 / 12 =83 333; plus náklady na přístup k tabulce (předpokládejme 1 čtení bloku na přístup, zde nemůžeme použít čtení z více bloků) =83 333; Celkové náklady =166 666.

Jak vidíte, náklady na Plán 1 (úplné skenování) jsou MENŠÍ než náklady na Plán 2 (indexové skenování + přístup přes rowid) – což znamená, že CBO by zvolil ÚPLNÉ skenování.

Pokud jsou předpoklady provedené optimalizátorem pravdivé, pak ve skutečnosti bude plán 1 výhodnější a mnohem efektivnější než plán 2 – což vyvrací mýtus, že ÚPLNÉ skenování je „vždy špatné“.

Výsledky by byly zcela odlišné, pokud by cílem optimalizátoru bylo FIRST_ROWS(n) místo ALL_ROWS – v takovém případě by optimalizátor upřednostnil plán 2, protože často vrátí prvních několik řádků rychleji, za cenu nižší účinnosti pro celý dotaz. .



  1. Převést text textového pole na celé číslo

  2. Jak Access komunikuje se zdroji dat ODBC? Část 3

  3. Jak nasadit aplikaci s databází serveru SQL na klientech

  4. Zastavit (dlouho) spouštění SQL dotazu v PostgreSQL, když relace nebo požadavky již neexistují?