Mówisz, że CAMPO47 jest wysoce selektywny. Ale filtrujesz tylko według IS NOT NULL. Nie ma więc znaczenia, ile ma odrębnych wartości, optymalizator nie użyje ich jako punktu wejścia.
A jak jest selektywny? Jak widać z liczności w planie wyjaśnień, wybranie STATO='SC' spowoduje znalezienie 12856 wierszy w tabeli. 12702 z tych oczywistych wierszy ma CAMPO47 z wartością, więc tylko 154 wiersze są odfiltrowywane przez test na nieważność. Gdyby optymalizator pociągnął za indeks w CAMPO47, ile wierszy by to zwróciło? Prawdopodobnie dużo więcej.
Optymalizator może używać tylko jednego indeksu sterty, aby uzyskać dostęp do wierszy w tabeli. (Mechanizm jest inny dla indeksów bitmapowych, gdy stosują transformację gwiazdy). Tak więc, jeśli uważasz, że dodatkowe dostępy do tabel są nie do zniesienia ciężarem, masz jedną opcję:indeks złożony. Jeśli STATO jest naprawdę nieselektywne (stosunkowo kilka wierszy), to prawdopodobnie możesz bezpiecznie zastąpić istniejący indeks jednym włączonym (STATO, CAMPO47).
Istnieje stara sztuczka polegająca na skłonieniu bazy danych do użycia indeksu w celu uzyskania dostępu do operacji IS NOT NULL, a polega ona na użyciu operandu, który może być prawdziwy tylko wtedy, gdy kolumna zawiera wartość. Na przykład coś takiego dla kolumn ciągów (zakładam, że coś o nazwie CAMPO47 po prostu musi być ciągiem):
AND campo47 >= chr(0)
To będzie pasować do każdej kolumny zawierającej jeden lub więcej znaków ascii. Nie jestem pewien, czy doprowadzi to do opisanej przez Ciebie optymalizacji „dwuindeksowej”, ale warto spróbować. (Przetestowałbym to sam, ale nie mam w tej chwili dostępu do bazy danych Oracle, a SQL Fiddle rzucił, gdy próbowałem zajrzeć do planu wyjaśniania)
