Warum verlangsamt die Suche nach null diese Abfrage?

Question

Ich habe diese Tabelle 7.000 Datensätze

ab ARADMIN.V_PKGXMLCODE

Name     Null  Type   
--------------------- -------- ------------- 
REQUEST_ID   NOT NULL VARCHAR2(15) 
AVAILABILITY     VARCHAR2(69) 
XML_CODE      CLOB   
PACKAGENAME_UNIQUE    VARCHAR2(50) 
CATALOG      NUMBER(15)  
CHILD       VARCHAR2(255) 
CLASSIFICATION_SYSTEM   NUMBER(15)  
E_MAIL       VARCHAR2(69) 

Die Abfrage

SELECT COUNT(*) FROM ARADMIN.V_PKGXMLCODE WHERE (CATALOG <> 0 AND CATALOG <> 2) AND (NOT (CHILD IS NULL)); 

dauert weniger als eine Sekunde enthält.

Die Abfrage

SELECT COUNT(*) FROM ARADMIN.V_PKGXMLCODE WHERE (CATALOG IS NULL OR (CATALOG <> 0 AND CATALOG <> 2)) AND (NOT (CHILD IS NULL)); 

dauert 23 Sekunden.

Erklären Plan jedoch behauptet, sollte es ganz schnell gehen ...

Was kann ich tun?

Answer 1

Das ist interessant. Ich würde erwarten, dass die Abfrage die gleiche Leistung hat, weil Oracle einen guten Optimierer hat und nicht von der NULL verwechselt werden sollte.

Wie funktioniert diese Version?

select x1.cnt + x2.cnt + x3.cnt 
from (select count(*) as cnt 
     from MYTABLE 
     where field4 = 1 and child is not null 
    ) x1 cross join 
    (select count(*) as cnt 
     from MYTABLE 
     where field4 = 4 and child is not null 
    ) x2 cross join 
    (select count(*) as cnt 
     from MYTABLE 
     where field4 is null and child is not null 
    ) x3; 

Diese Version sollte auf MYTABLE(field4, child) Vorteil eines Index zu übernehmen können.

Answer 2

Die einzige Art, wie ich auf field4 einen Index (a) wäre haben diese Art von Unterschied in der Ausführungsgeschwindigkeit zu bekommen denken kann, und (b) einen viele von leeren Datenblöcken; möglicherweise von einer hohen Wassermarke, die durch wiederholte Direktweglasten sehr hoch eingestellt ist.

Die erste Abfrage würde immer noch den Index verwenden und wie erwartet ausführen. Da Nullwerte jedoch nicht indiziert sind, kann der Index nicht zur Überprüfung der or field4 is null-Bedingung verwendet werden, sodass er auf einen vollständigen Tabellenscan zurückfällt.

Das sollte an sich kein Problem sein, da ein vollständiger Tabellenscan von 7000 Zeilen nicht lange dauern sollte. Aber seit es so lange dauert, ist etwas anderes los. Ein vollständiger Tabellenscan muss jeden der Tabelle zugewiesenen Datenblock untersuchen, um zu sehen, ob sie Zeilen enthalten, und die dafür benötigte Zeit lässt darauf schließen, dass selbst bei Inline-CLOB-Speicher mehr Blöcke als 7000 Zeilen vorhanden sind.

Der einfachste Weg, um viele leere Datenblöcke zu bekommen, ist, eine Menge Daten zu haben und dann den größten Teil davon zu löschen. Aber ich glaube, Sie haben in einem jetzt gelöschten Kommentar zu einer früheren Frage gesagt, dass die Leistung früher in Ordnung war und sich verschlechtert hat. Das kann passieren, wenn Sie direct-path inserts tun, insbesondere wenn Sie Daten "löschen", indem Sie sie löschen und dann neue Daten im Direktpfad-Modus einfügen. Sie könnten das mit Inserts tun, die den /*+ append */ Hinweis haben; oder parallel; oder über SQL * Loader. Jedes Mal, wenn Sie das tun, würde sich die Hochwassermarke bewegen, da alte leere Blöcke nicht wiederverwendet werden würden; und jedes Mal würde sich die Leistung der Abfrage, die auf Nullen prüft, etwas verschlechtern. Nach vielen Iterationen würde das wirklich beginnen sich zu summieren.

Sie können das Datenwörterbuch überprüfen, um zu sehen, wie viel Platz Ihrer Tabelle zugewiesen ist (user_segments usw.), und vergleichen Sie das mit der Größe der Daten, die Sie tatsächlich denken. Sie können die HWM zurücksetzen, indem Sie die Tabelle neu erstellen, z.g by doing: (! vorzugsweise in einem Wartungsfenster)

alter table mytable move; 

Als Demo lief ich einen Zyklus Einsatz zu leiten Pfad und löschen 7000 Zeilen über hundertmal, und dann liefen beide Ihre Fragen . Der erste dauerte 0,06 Sekunden (viel davon ist SQL Devleoper Overhead); der zweite dauerte 1.260. (Ich fuhr auch Gordon, der eine ähnliche Zeit bekam, da es immer noch eine FTS zu tun hat). Mit mehr Iterationen würde der Unterschied noch stärker werden, aber ich hatte keinen Platz mehr ... Dann habe ich einen alter table move gemacht und die zweite Abfrage erneut ausgeführt, was dann 0,05 Sekunden dauerte.