Sie sagen, CAMPO47 sei hochselektiv. Aber Sie filtern nur nach IS NOT NULL. Es spielt also keine Rolle, wie viele unterschiedliche Werte es hat, der Optimierer wird es nicht als Einstiegspunkt verwenden.
Und wie selektiv ist es? Wie Sie anhand der Kardinalitäten im Erklärplan sehen können, findet die Auswahl von STATO='SC' 12856 Zeilen in Ihrer Tabelle. 12702 dieser Zeilen haben offensichtlich CAMPO47 mit einem Wert, sodass nur 154 Zeilen durch den Test auf Nichtigkeit herausgefiltert werden. Wenn der Optimierer den Index auf CAMPO47 gewählt hätte, wie viele Zeilen hätte das zurückgegeben? Wahrscheinlich noch viel mehr.
Der Optimierer kann nur einen Heap-Index verwenden, um auf Zeilen in einer Tabelle zuzugreifen. (Der Mechanismus ist für Bitmap-Indizes anders, wenn sie eine Sterntransformation anwenden). Wenn Sie also denken, dass die zusätzlichen Tabellenzugriffe eine unerträgliche Belastung sind, haben Sie eine Option:einen zusammengesetzten Index. Wenn STATO wirklich nicht selektiv ist (relativ wenige Zeilen), können Sie den vorhandenen Index wahrscheinlich sicher durch einen ersetzen (STATO, CAMPO47).
Es gibt einen alten Trick, um die Datenbank dazu zu bringen, einen Index für den Zugriff auf IS NOT NULL-Operationen zu verwenden, und zwar einen Operanden zu verwenden, der nur dann wahr sein kann, wenn die Spalte einen Wert enthält. Zum Beispiel so etwas für String-Spalten (ich nehme an, etwas namens CAMPO47 muss einfach ein String sein):
AND campo47 >= chr(0)
Das stimmt mit jeder Spalte überein, die ein oder mehrere ASCII-Zeichen enthält. Ich bin mir nicht sicher, ob es zu der von Ihnen beschriebenen "Zwei-Index" -Optimierung führen wird, aber es ist einen Versuch wert. (Ich würde das selbst testen, aber ich habe gerade keinen Zugriff auf eine Oracle-Datenbank, und SQL Fiddle schleuderte, als ich versuchte, mir den Explain-Plan anzusehen)
