U zegt dat CAMPO47 zeer selectief is. Maar je filtert alleen op IS NOT NULL. Het maakt dus niet uit hoeveel verschillende waarden het heeft, de optimizer zal het niet als startpunt gebruiken.
En hoe selectief is het? Zoals je kunt zien aan de kardinaliteiten in het plan uitleggen, vind je door op STATO='SC' te selecteren 12856 rijen in je tabel. 12702 van die rijen hebben duidelijk CAMPO47 met een waarde, dus slechts 154 rijen worden eruit gefilterd door de test op nietigheid. Als de optimizer de index op CAMPO47 had geplunderd, hoeveel rijen zou dat dan hebben opgeleverd? Waarschijnlijk veel meer.
De optimizer kan slechts één heapindex gebruiken om toegang te krijgen tot rijen in een tabel. (Het mechanisme is anders voor bitmapindexen wanneer ze een stertransformatie toepassen). Dus als u denkt dat de extra toegang tot tabellen een ondraaglijke last is, dan heeft u één optie:een samengestelde index. Als STATO echt niet-selectief is (relatief weinig rijen), dan kun je waarschijnlijk veilig de bestaande index vervangen door een aan (STATO, CAMPO47).
Er is een oude truc om de database ertoe aan te zetten een index te gebruiken om toegang te krijgen tot IS NOT NULL-bewerkingen, en dat is om een operand te gebruiken die alleen waar kan zijn als de kolom een waarde bevat. Bijvoorbeeld zoiets voor stringkolommen (ik neem aan dat iets dat CAMPO47 heet gewoon een string moet zijn):
AND campo47 >= chr(0)
Dat komt overeen met elke kolom die een of meer ascii-tekens bevat. Ik weet niet zeker of dit zal leiden tot de "twee index"-optimalisatie die u beschrijft, maar het is het proberen waard. (Ik zou dit zelf testen, maar ik heb op dit moment geen toegang tot een Oracle-database, en SQL Fiddle slingerde toen ik probeerde naar het Explain Plan te kijken)