Dices que CAMPO47 es muy selectivo. Pero solo está filtrando NO ES NULO. Por lo tanto, no importa cuántos valores distintos tenga, el optimizador no lo usará como punto de entrada.
¿Y qué tan selectivo es? Como puede ver en las cardinalidades en el plan de explicación, seleccionar STATO='SC' encuentra 12856 filas en su tabla. 12702 de esas filas obviamente tienen CAMPO47 con un valor, por lo que la prueba de nulidad filtra solo 154 filas. Si el optimizador hubiera buscado el índice en CAMPO47, ¿cuántas filas habría devuelto? Probablemente mucho más.
El optimizador solo puede usar un índice de montón para acceder a las filas de una tabla. (El mecanismo es diferente para los índices de mapa de bits cuando aplican una transformación en estrella). Entonces, si cree que los accesos adicionales a la tabla son una carga insufrible, entonces tiene una opción:un índice compuesto. Si STATO es realmente no selectivo (relativamente pocas filas), entonces probablemente esté seguro reemplazando el índice existente con uno en (STATO, CAMPO47).
Hay un viejo truco para empujar a la base de datos a usar un índice para acceder a las operaciones IS NOT NULL, y es usar un operando que solo puede ser verdadero donde la columna contiene un valor. Por ejemplo, algo como esto para las columnas de cadena (supongo que algo llamado CAMPO47 tiene que ser una cadena):
AND campo47 >= chr(0)
Eso coincidirá con cualquier columna que contenga uno o más caracteres ASCII. No estoy seguro de si conducirá a la optimización de "dos índices" que describe, pero vale la pena intentarlo. (Probaría esto yo mismo, pero no tengo acceso a una base de datos de Oracle en este momento, y SQL Fiddle se lanzó cuando traté de ver el plan de explicación)
