Какви са последиците за производителността на Oracle IN Clause без обединения?

Ако статистическите данни за вашата таблица са точни, трябва да е много малко вероятно оптимизаторът да избере да направи сканиране на таблица, вместо да използва индекса на първичния ключ, когато имате само 1000 твърдо кодирани елемента в WHERE клауза. Най-добрият подход би бил да съберете (или зададете) точни статистически данни за вашите обекти, тъй като това трябва да доведе до автоматично случване на добри неща, вместо да се опитвате да правите много гимнастика, за да заобиколите неправилни статистики.

Ако приемем, че статистиката е неточна до степен, в която оптимизаторът ще бъде накаран да повярва, че сканирането на таблица би било по-ефективно от използването на индекса на първичния ключ, потенциално бихте могли да добавите DYNAMIC_SAMPLING намек, който би принудил оптимизатора да събере по-точни статистически данни, преди да оптимизира израза или CARDINALITY намек за замяна на оценката на кардиналността по подразбиране на оптимизатора. Нито едно от тях не би изисквало да се знае нищо за наличните индекси, просто би било необходимо да се знае псевдонимът на таблицата (или името, ако няма псевдоним). DYNAMIC_SAMPLING би бил по-безопасният, по-стабилен подход, но би добавил време към стъпката на анализиране.

Ако изграждате SQL израз с променлив брой твърдо кодирани параметри в IN клауза, вероятно ще си създавате проблеми с производителността, като наводнявате споделения си пул с неподеляем SQL и принуждавате базата данни да прекарва много време в усилен анализ на всеки вариант поотделно. Би било много по-ефективно, ако създадете единичен споделен SQL оператор, който може да бъде анализиран веднъж. В зависимост от това къде сте IN стойностите на клауза идват от, което може да изглежда нещо като

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

или

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

или

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

Ако се сведете до един SQL оператор, който може да се споделя, тогава в допълнение към избягването на разходите за постоянно повторно анализиране на оператора, ще имате редица опции за налагане на определен план, който не включва модифициране на SQL оператора. Различните версии на Oracle имат различни опции за стабилност на плана-- има съхранени контури , управление на SQL план и SQL профили сред другите технологии в зависимост от вашата версия. Можете да ги използвате, за да принудите конкретни планове за определени SQL изрази. Ако обаче продължавате да генерирате нови SQL изрази, които трябва да бъдат повторно анализирани, използването на тези технологии става много трудно.