Dici che CAMPO47 è altamente selettivo. Ma stai solo filtrando IS NOT NULL. Quindi non importa quanti valori distinti abbia, l'ottimizzatore non lo utilizzerà come punto di ingresso.
E quanto è selettivo? Come puoi vedere dalle cardinalità nel piano di spiegazione, selezionando STATO='SC' troverai 12856 righe nella tua tabella. 12702 di quelle righe ovvie hanno CAMPO47 con un valore, quindi solo 154 righe vengono filtrate dal test di nullità. Se l'ottimizzatore avesse eseguito il plumping per l'indice su CAMPO47, quante righe sarebbero state restituite? Probabilmente molto di più.
L'ottimizzatore può utilizzare solo un indice di heap per accedere alle righe di una tabella. (Il meccanismo è diverso per gli indici bitmap quando applicano una trasformazione a stella). Quindi, se ritieni che gli accessi aggiuntivi alle tabelle siano un onere insopportabile, hai un'opzione:un indice composto. Se STATO è veramente non selettivo (relativamente poche righe), allora probabilmente sei sicuro di sostituire l'indice esistente con uno attivo (STATO, CAMPO47).
C'è un vecchio trucco per spingere il database a usare un indice per accedere alle operazioni IS NOT NULL, e cioè usare un operando che può essere vero solo dove la colonna contiene un valore. Ad esempio, qualcosa del genere per le colonne di stringhe (suppongo che qualcosa chiamato CAMPO47 debba essere solo una stringa):
AND campo47 >= chr(0)
Ciò corrisponderà a qualsiasi colonna che contiene uno o più caratteri ascii. Non sono sicuro se porterà all'ottimizzazione dei "due indici" che descrivi, ma vale la pena provare. (Lo proverei io stesso ma non ho accesso a un database Oracle in questo momento e SQL Fiddle si è lanciato quando ho provato a guardare l'Explain Plan)
