Oracle nicht mit index beim Eintritt in

Ich bin sehr neu zu indizieren und zu erklären, Pläne, also bitte Geduld mit mir!
Ich versuche zum optimieren einer Abfrage, aber ich bin Probleme.

Ich habe zwei Tabellen:

SKU
------
SKUIDX (Unique index)
CLRIDX (Index)
..
..

IMPCOST_CLR
-----------
ICCIDX (Unique index)
CLRIDX (Index)
...
..

Wenn ich eine select * from SKU where clridx = 122 ich kann sehen, dass es mit dem index in den explain-plan (es sagt-TABELLE, ACCESS,.. INDEX, sagt es, dass der index unter dem Namen OBJEKTNAME und die Optionen ist der RANGE-SCAN).

Nun, wenn ich versuche, gemeinsam auf dem gleichen Feld, es erscheint nicht auf den index verwenden (es sagt-TABELLE, ACCESS,.. die HASH-JOIN-und unter "Optionen", heißt es VOLLER).

Was sollte ich suchen, um zu versuchen und sehen, warum es nicht über den index?
Sorry, ich bin nicht sicher, welche Befehle zu geben, um dies zu zeigen, so bitte lassen Sie mich wissen, wenn Sie weitere Informationen benötigen.

Beispiele:

1. Abfrage:

  SELECT
    *
  FROM
    AP21.SKU
  WHERE
    CLRIDX = 100

Oracle nicht mit index beim Eintritt in

2. Abfrage: 

  SELECT
    *
  FROM
    AP21.IMPCOST_CLR
  WHERE
    CLRIDX = 100

Oracle nicht mit index beim Eintritt in

3. Abfrage:

  SELECT
    *
  FROM
    AP21.SKU
  INNER JOIN
    AP21.IMPCOST_CLR ON
    IMPCOST_CLR.CLRIDX = SKU.CLRIDX

Oracle nicht mit index beim Eintritt in

  • Was ist die Abfrage, die Sie verwenden, wenn Sie sich anmelden?
  • Hi, siehe mein edit. Die Abfrage im Versuch optimieren Hunderte und viel mehr, aber es brechen und nehmen es Schritt für Schritt!
  • Wie haben Sie bei der Lösung Ihres vollständigen scan problem?
  • durch das Verständnis, wie SQL und Abfragen arbeiten 🙂 Siehe Antwort unten
InformationsquelleAutor Lock | 2013-07-16
  1. 18

    Blick auf diese Abfrage:

    SELECT
    *
FROM
    AP21.SKU
INNER JOIN
    AP21.IMPCOST_CLR ON
    IMPCOST_CLR.CLRIDX = SKU.CLRIDX

    Es hat keine zusätzlichen Prädikaten. So Gesellen Sie alle Zeilen in SKU, um alle Zeilen in IMPCOST_CLR. Außerdem wählen Sie alle Spalten aus beiden Tabellen.

    Dies bedeutet, Oracle hat die Gesamtheit der beiden Tabellen. Der effizienteste Weg dies zu tun ist die Verwendung von Full Table Scan, zu schöpfen, bis Sie alle Zeilen, die in den multi-block liest, und verwenden Sie hashing zu den Werten entsprechen, die den Beitritt.

    Im Grunde ist es ein Betrieb, das ist, was SQL nicht sehr gut, in der Erwägung, dass indizierte Lesevorgänge mehr RBAR. Nun, wenn Sie verändert die Dritte Abfrage ein zusätzliches Prädikat, wie

    WHERE SKU.CLRIDX = 100

    würden Sie wahrscheinlich sehen, den Zugriff auf Pfad wiederherstellen INDEX-RANGE-SCAN . Da hast du nur die Auswahl einer vergleichsweise Handvoll Zeilen, so dass das indizierte Lesen ist der effizientere Weg noch einmal.

    "Die Abfrage im Versuch optimieren Hunderte und viel mehr, aber das brechen
    Sie es auf und nehmen es Schritt für Schritt! "

    Dies ist eine gute Technik, aber Sie brauchen, um zu verstehen, wie die Oracle-optimzer funktioniert. Es gibt viele Informationen in den Explain-Plan. Finden Sie mehr heraus. Achten Sie auf den Wert in der Rows Spalte für jeden Schritt. Das sagt dir, wie viele Zeilen der Optimierer rechnet man aus dem Betrieb. Sie werden sehen, sehr unterschiedliche Werte für die ersten beiden Abfragen gegenüber dem Dritten.

    • Gibt es eine Möglichkeit zu vermeiden, um die vollständige Untersuchung in diesem Fall?
    • in diesem Fall ist der Full Table Scan ist der effizienteste Weg, um auf die Daten zugreifen. Also, warum würden Sie wollen, um es zu vermeiden?
    InformationsquelleAutor APC
  2. 6

    Nun, wenn ich versuche, gemeinsam auf dem gleichen Feld, wird er nicht angezeigt
    verwenden Sie den index (es sagt-TABELLE, ACCESS,.. die HASH-JOIN-und unter
    Optionen, heißt es VOLL ist).

    Es ist, weil die HASH-JOIN nicht verwenden (müssen), Indizes für die join-Prädikate:

    http://use-the-index-luke.com/sql/join/hash-join-partial-objects

    InformationsquelleAutor Markus Winand
Schreibe einen Kommentar