Jaké jsou výkonnostní důsledky doložky Oracle IN bez připojení?

Pokud jsou statistiky ve vaší tabulce přesné, mělo by být velmi nepravděpodobné, že by se optimalizátor rozhodl provést skenování tabulky místo použití indexu primárního klíče, když máte pouze 1000 pevně zakódovaných prvků v WHERE doložka. Nejlepším přístupem by bylo shromáždit (nebo nastavit) přesné statistiky o vašich objektech, protože to by mělo způsobit, že se dobré věci budou dít automaticky, spíše než se snažit dělat spoustu gymnastiky, abyste se vyhnuli nesprávným statistikám.

Pokud předpokládáme, že statistiky jsou nepřesné do té míry, že by optimalizátor přivedl k domněnce, že skenování tabulky by bylo efektivnější než použití indexu primárního klíče, můžete potenciálně přidat DYNAMIC_SAMPLING nápověda, která by optimalizátora nutila shromáždit přesnější statistiky před optimalizací příkazu nebo CARDINALITY nápověda k přepsání výchozího odhadu mohutnosti optimalizátoru. Ani jeden z nich by nevyžadoval znát nic o dostupných indexech, vyžadovalo by to pouze znalost aliasu tabulky (nebo názvu, pokud žádný alias neexistuje). DYNAMIC_SAMPLING byl by to bezpečnější a robustnější přístup, ale prodloužil by to krok analýzy.

Pokud vytváříte SQL příkaz s proměnným počtem pevně zakódovaných parametrů v IN klauzule, pravděpodobně si způsobíte problémy s výkonem tím, že zaplavíte svůj sdílený fond nesdílitelným SQL a donutíte databázi, aby trávila spoustu času usilovnou analýzou každé varianty zvlášť. Bylo by mnohem efektivnější, kdybyste vytvořili jeden sdílený SQL příkaz, který by bylo možné analyzovat jednou. Podle toho, kde jste IN hodnoty klauzule pocházejí, to by mohlo vypadat nějak takto

SELECT *
  FROM table_name
 WHERE primary_key IN (SELECT primary_key
                         FROM global_temporary_table);

nebo

SELECT *
  FROM table_name
 WHERE primary_key IN (SELECT primary_key
                         FROM TABLE( nested_table ));

nebo

SELECT *
  FROM table_name
 WHERE primary_key IN (SELECT primary_key
                         FROM some_other_source);

Pokud byste se dostali až k jedinému sdílenému příkazu SQL, pak kromě toho, že se vyhnete nákladům na neustálé opětovné analyzování příkazu, budete mít řadu možností, jak vynutit konkrétní plán, který nezahrnuje úpravu příkazu SQL. Různé verze Oracle mají různé možnosti stability plánu – jsou zde uložené obrysy , Správa plánu SQL a profily SQL mimo jiné technologie v závislosti na vaší verzi. Můžete je použít k vynucení konkrétních plánů pro konkrétní příkazy SQL. Pokud však neustále generujete nové příkazy SQL, které je třeba znovu analyzovat, bude použití těchto technologií velmi obtížné.