Jeśli statystyki w Twojej tabeli są dokładne, jest bardzo mało prawdopodobne, że optymalizator wybierze skanowanie tabeli zamiast używania indeksu klucza podstawowego, gdy masz tylko 1000 zakodowanych na stałe elementów w WHERE klauzula. Najlepszym podejściem byłoby zbieranie (lub ustawianie) dokładnych statystyk dotyczących obiektów, ponieważ powinno to spowodować automatyczne dzianie się dobrych rzeczy, zamiast próbować dużo gimnastyki w celu obejścia nieprawidłowych statystyk.
Jeśli założymy, że statystyki są niedokładne do tego stopnia, że optymalizator mógłby sądzić, że skanowanie tabeli byłoby bardziej wydajne niż użycie indeksu klucza podstawowego, można potencjalnie dodać DYNAMIC_SAMPLING wskazówka, która zmusiłaby optymalizator do zebrania dokładniejszych statystyk przed optymalizacją instrukcji lub CARDINALITY wskazówka, aby zastąpić domyślne oszacowanie kardynalności optymalizatora. Żadna z nich nie wymagałaby znajomości dostępnych indeksów, wystarczyłaby znajomość aliasu tabeli (lub nazwy, jeśli nie ma aliasu). DYNAMIC_SAMPLING byłoby bezpieczniejszym, bardziej niezawodnym podejściem, ale wydłużyłoby czas na etapie parsowania.
Jeśli tworzysz instrukcję SQL ze zmienną liczbą zakodowanych na stałe parametrów w IN klauzula, prawdopodobnie będziesz stwarzać sobie problemy z wydajnością, zalewając współużytkowaną pulę nieudostępnialnym kodem SQL i zmuszając bazę danych do spędzania dużej ilości czasu na twardym analizowaniu każdego wariantu osobno. Byłoby znacznie wydajniej, gdybyś utworzył pojedynczą współdzieloną instrukcję SQL, którą można by raz przeanalizować. W zależności od tego, gdzie Twój IN pochodzą wartości klauzul, które mogą wyglądać mniej więcej tak
SELECT *
FROM table_name
WHERE primary_key IN (SELECT primary_key
FROM global_temporary_table);
lub
SELECT *
FROM table_name
WHERE primary_key IN (SELECT primary_key
FROM TABLE( nested_table ));
lub
SELECT *
FROM table_name
WHERE primary_key IN (SELECT primary_key
FROM some_other_source);
Jeśli sprowadziłbyś się do pojedynczej udostępnianej instrukcji SQL, to oprócz unikania kosztów ciągłego ponownego analizowania instrukcji, miałbyś kilka opcji wymuszania konkretnego planu, które nie wymagają modyfikowania instrukcji SQL. Różne wersje Oracle mają różne opcje stabilności planu — istnieją przechowywane kontury , Zarządzanie planem SQL oraz profile SQL między innymi technologiami w zależności od wersji. Możesz ich użyć do wymuszenia określonych planów dla określonych instrukcji SQL. Jeśli jednak będziesz nadal generować nowe instrukcje SQL, które muszą być ponownie analizowane, korzystanie z tych technologii staje się bardzo trudne.
