Willkommen bei Entwickler-Forum.
Ergebnis 1 bis 6 von 6
  1. #1
    Stammgast
    Registriert seit
    21.09.2010
    Beiträge
    125

    Standard Oracle Index Optimizer Frage

    Hallo zusammen,

    ich habe folgendes Verhalten beobachtet:

    Tabelle "Mitarbeiter" hat drei Nummer Spalten A, B und C.
    Ein zusammengesetzter Standard Index ist auf A + B + C angelegt.
    Teilweise steht in A, B und C der gleiche Wert, "-1".

    SQL 1 = Where A = -1
    SQL 2 = Where A = -1 and B = -1
    SQL 3 = Where A = -1 and B = -1 and C = -1

    Der Ausführungsplan ist bei SQL 3 am besten und SQL 1 am schlechtesten.
    Mein Verständnis wäre gewesen, dass Oracle bei der Baumstruktur schneller fertig ist wenn bei einem spaltenübergreifenden Index nur die erste Spalte gelesen werden muss.
    Warum ist das nicht so?

    Viele Grüße

  2. #2
    Forenheld
    Registriert seit
    26.02.2003
    Beiträge
    16.317

    Standard

    Hast du die Statistik erneuert nach dem einfügen der Daten?
    Bei einem zusammengesetzen Index kann man die Spalten nicht per se einzeln verwenden. GGf. beachte die Reihenfolge des Indexes
    Geändert von Christian Marquardt (27.06.2018 um 16:06 Uhr)
    Christian

  3. #3
    Stammgast
    Registriert seit
    21.09.2010
    Beiträge
    125

    Standard

    Ja die Statistiken sind aktuell. Der Index wird in jedem Fall benutzt, da er auch in dieser Reihenfolge, also erst Spalte A, dann B, dann C erstellt worden ist.

  4. #4
    Forenheld
    Registriert seit
    26.02.2003
    Beiträge
    16.317

    Standard

    https://use-the-index-luke.com/de/sq...zte-schluessel

    Was hast du denn nun? Einen zusammengesetzen Index oder einen je Spalte?
    Christian

  5. #5
    Stammgast
    Registriert seit
    21.09.2010
    Beiträge
    125

    Standard

    Einen zusammengesetzten Index, in der Reihenfolge A, B, C.
    Oracle kann den Index auch benutzen wenn man nur auf A abfragt.
    Teilweise auch wenn man nur B oder C abfragt, wenn ein Skip Scan möglich / sinnvoll ist.

  6. #6
    Stammgast
    Registriert seit
    24.10.2011
    Beiträge
    1.366

    Standard

    Zitat Zitat von FlexGer Beitrag anzeigen
    Einen zusammengesetzten Index, in der Reihenfolge A, B, C.
    Oracle kann den Index auch benutzen wenn man nur auf A abfragt.
    Teilweise auch wenn man nur B oder C abfragt, wenn ein Skip Scan möglich / sinnvoll ist.
    Hab ich Dich richtig verstanden, dass fast immer das gleiche drin steht?
    Dann wäre es ein Ergebnis schlechter "Selektivität". Ein Index, der Millionen gleicher Einträge verwaltet ist mehr oder weniger nutzlos. Mit der Varianz (SQL 3) wird die Selektivität stärker und der Index eher genutzt. Hab jetzt nicht geschaut, was Du alles geschrieben, probiert hast, aber es könnte sein, dass Oracle einfach "denkt", was soll das? das Index bringt nichts, ich nehm full table scan.
    Ok, noch mal geschaut, das -1 steht vermutlich nicht überall drin, sondern nur "manchmal". Vielleich tein Ersatz für Null, weil eine Referenz/Wert noch nicht da ist? Sind solche "Lücken" hinreichend oft vorhanden, tritt ebenfalls das ein, was ich oben schrieb.

    Aber:
    Das Ganze gilt nur, wenn diese Where Bedingung die einzige ist. (Was vielleicht im Rahmen einer Mitarbeiterbearbeitung ungewöhnlich wäre).
    Falls es doch so ist, wäre zu überlegen, ob man die Selektivität pushen kann indem man andere Kriterien reinbringt, bspw. Date Range oder sowas (hinreichend groß natürlich und ggF. nach oben (zukunft) gedeckelt mit sysdate+1 oder so, es sollte natürlich so sicher sein, dass Dir nicht irgendwann durch diese Konstruktion Daten in einer Standardoperation oder -Auswertung fehlen)
    Wie auch immer, greift ein solcher Index, dann wird auch hier der Mehrfachindex u.U. gar nicht mehr genutzt (kann nicht mehr genutzt werden). Was dann idealer Weise bei hinreichend kleinem (Zwischen-)Ergebnis egal wäre (ich nenn es immer Kopfrechnen für die DB).
    Gruß, defo

 

 

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •