system

Diese Tabelle hat nur einen Datensatz (Systemtabelle). Dies ist ein Sonderfall des Join-Typs const.

const

Die Tabelle hat maximal einen passenden Datensatz, der beim Start der Abfrage gelesen wird. Da nur ein Datensatz vorhanden ist, können die Werte aus den Spalten dieses Datensatzes vom Optimierer im Folgenden als Konstanten behandelt werden. const-Tabellen sind sehr schnell, da sie nur einmal gelesen werden.

const wird verwendet, wenn Sie alle Teile eines Primärschlüssels oder eines eindeutigen Indexes mit Konstantenwerten vergleichen. In der folgenden Abfrage kann tbl_name als const-Tabelle verwendet werden:

 SELECT * FROM tbl_name WHERE
primary_key=1;

SELECT * FROM tbl_name WHERE
primary_key_part1=1 AND
primary_key_part2=2; 

eq_ref

Für jede Datensatzkombination aus den vorherigen Tabellen wird genau ein Datensatz aus dieser Tabelle gelesen. Anders als die Typen system und const ist dies der beste Join-Typ. Er wird verwendet, wenn alle Teile eines Indexes vom Join verwendet werden und der Index ein Primärschlüssel oder ein eindeutiger Index ist.

eq_ref kann für indizierte Spalten benutzt werden, die mithilfe des Operators = verglichen werden. Der Vergleichswert kann eine Konstante oder ein Ausdruck sein, der Spalten aus Tabellen verwendet, die vor dieser Tabelle gelesen wurden. In den folgenden Beispielen kann MySQL einen eq_ref-Join zur Verarbeitung von ref_table verwenden:

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;

ref

Alle Datensätze mit passenden Indexwerten werden aus dieser Tabelle für jede Kombination von Datensätzen in den vorherigen Tabellen gelesen. ref wird benutzt, wenn der Join nur ein linkes Präfix des Schlüssels verwendet oder der Schlüssel kein Primärschlüssel und auch kein eindeutiger Index ist (d. h., wenn der Join keinen einzelnen Datensatz basierend auf dem Schlüsselwert auswählen kann). Wenn der verwendete Schlüssel nur einigen wenigen Datensätzen entspricht, ist dies ein guter Join-Typ.

ref kann für indizierte Spalten benutzt werden, die mithilfe der Operatoren = oder <=> verglichen werden. In den folgenden Beispielen kann MySQL einen ref-Join zur Verarbeitung von ref_table verwenden:

 SELECT * FROM ref_table WHERE
key_column=expr;

SELECT * FROM
ref_table,other_table
WHERE
ref_table.key_column=other_table.column;

SELECT * FROM
ref_table,other_table
WHERE
ref_table.key_column_part1=other_table.column
AND
ref_table.key_column_part2=1;

ref_or_null

Dieser Join-Typ ähnelt ref weitgehend, allerdings führt MySQL hierbei eine zusätzliche Suche nach Datensätzen durch, die NULL-Werte enthalten. Diese Join-Typ-Optimierung wird meistens bei der Auflösung von Unterabfragen verwendet. In den folgenden Beispielen kann MySQL einen ref_or_null-Join zur Verarbeitung von ref_table verwenden:

 SELECT * FROM ref_table WHERE
key_column=expr OR
key_column IS NULL; 

Siehe auch Abschnitt 7.2.7, „IS NULL-Optimierung“.

index_merge

Dieser Join-Typ gibt an, dass die Indexverschmelzungsoptimierung verwendet wird. In diesem Fall enthält die Spalte key im ausgegebenen Datensatz eine Liste der verwendeten Indizes, und key_len enthält eine Liste der längsten Schlüsselteile für die verwendeten Indizes. Weitere Informationen finden Sie unter Abschnitt 7.2.6, „Optimierung durch Indexverschmelzung“.

unique_subquery

Dieser Typ ersetzt ref in einigen IN-Unterabfragen der folgenden Form:

 value IN (SELECT
primary_key FROM
single_table WHERE
some_expr) 

unique_subquery ist eine Nachschlagefunktion für Indizes, die zur Effizienzsteigerung die Unterabfrage vollständig ersetzt.

index_subquery

Dieser Join-Typ ähnelt unique_subquery. Er ersetzt IN-Unterabfragen, funktioniert aber bei nichteindeutigen Indizes in Unterabfragen folgender Form:

 value IN (SELECT
key_column FROM
single_table WHERE
some_expr) 

range

Es werden nur Datensätze abgerufen, die in einem gegebenen Bereich liegen. Sie werden anhand eines Indexes ausgewählt. Die Spalte key im Ausgabedatensatz zeigt an, welcher Index verwendet wird. key_len enthält den längsten verwendeten Schlüsselteil. Die Spalte ref ist für diesen Typ NULL.

range kann verwendet werden, wenn eine Schlüsselspalte unter Verwendung eines der Operatoren =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN oder IN mit einer Konstante verglichen wird:

SELECT * FROM tbl_name
  WHERE key_column = 10;

SELECT * FROM tbl_name
  WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name
  WHERE key_column IN (10,20,30);

SELECT * FROM tbl_name
  WHERE key_part1= 10 AND key_part2 IN (10,20,30);

index

Dieser Join-Typ ist mit ALL bis auf die Tatsache identisch, dass nur der Indexbaum gescannt wird. Insofern ist er in der Regel schneller als ALL, weil die Indexdatei gewöhnlich kleiner ist als die Datendatei.

MySQL kann diesen Join-Typ verwenden, wenn die Abfrage nur Spalten benutzt, die Teil eines einzelnen Indexes sind.

ALL

Ein vollständiger Tabellenscan wird für jede Kombination von Datensätzen aus den vorherigen Tabellen durchgeführt. Dies ist normalerweise nicht von Vorteil, wenn die Tabelle die erste nicht als const gekennzeichnete Tabelle ist, und in allen anderen Fällen sogar ganz schlimm. Sie können ALL normalerweise vermeiden, indem Sie Indizes hinzufügen, die das Abrufen von Datensätzen aus der Tabelle basierend auf Konstanten- oder Spaltenwerten aus früheren Tabellen erlauben.

Distinct

MySQL sucht nach unterschiedlichen Werten, d. h., die Suche nach weiteren Datensätzen zur aktuellen Datensatzkombination wird beendet, sobald der erste Datensatz gefunden wurde.

Not exists

MySQL konnte eine LEFT JOIN-Optimierung an der Abfrage vornehmen und untersucht für die vorhergehende Datensatzkombination keine weiteren Datensätze in dieser Tabelle, sobald ein Datensatz gefunden wurde, der den LEFT JOIN-Kriterien entspricht. Hier ein Beispiel für einen Abfragetyp, der auf diese Weise optimiert werden kann:

SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
  WHERE t2.id IS NULL;

Nehmen wir an, t2.id sei als NOT NULL definiert. In diesem Fall scannt MySQL t1 und sucht die Datensätze in t2 unter Verwendung der Werte aus t1.id heraus. Findet MySQL einen passenden Datensatz in t2, dann weiß es, dass t2.id niemals NULL sein kann, und scannt die weiteren Datensätze in t2, die denselben id-Wert aufweisen, nicht mehr. Für jeden Datensatz in t1 muss MySQL also nur einen einzigen Suchvorgang in t2 durchführen – unabhängig davon, wie viele entsprechende Datensätze in t2 tatsächlich vorhanden sind.

range checked for each record (index map: N)

MySQL hat keinen geeigneten Index gefunden, aber festgestellt, dass einige der Indizes verwendet werden könnten, nachdem Spaltenwerte aus vorhergehenden Tabellen bekannt geworden sind. Für jede Datensatzkombination in den vorherigen Tabellen überprüft MySQL, ob es möglich ist, zum Abrufen von Datensätzen eine der Zugriffsmethoden range oder index_merge zu verwenden. Dies ist nicht sehr schnell, aber immer noch schneller als die Durchführung eines Joins ohne Index. Die Anwendbarkeitskriterien entsprechen den in Abschnitt 7.2.5, „Bereichsoptimierung“, und Abschnitt 7.2.6, „Optimierung durch Indexverschmelzung“, beschriebenen, nur sind hier alle Spaltenwerte für die vorhergehende Tabelle bekannt und werden als Konstanten betrachtet.

Using filesort

MySQL muss einen zusätzlichen Durchlauf vornehmen, um zu ermitteln, wie die Datensätze in sortierter Reihenfolge abgerufen werden können. Diese Sortierung erfolgt, indem alle Datensätze entsprechend dem Join-Typ überprüft und Sortierschlüssel sowie der Zeiger auf den Datensatz für alle Datensätze gespeichert werden, die der WHERE-Klausel entsprechen. Die Schlüssel werden dann sortiert und die Datensätze entsprechend in sortierter Reihenfolge abgerufen. Siehe auch Abschnitt 7.2.12, „ORDER BY-Optimierung“.

Using index

Die Spaltendaten werden ausschließlich unter Verwendung von Angaben im Indexbaum aus der Tabelle abgerufen – es erfolgt kein zusätzlicher Suchvorgang, um jeweils den eigentlichen Datensatz auszulesen. Diese Strategie kann verwendet werden, wenn die Abfrage nur Spalten benutzt, die Teil eines einzelnen Indexes sind.

Using temporary

Um die Abfrage aufzulösen, muss MySQL eine Temporärtabelle zur Aufnahme des Ergebnisses erstellen. Dies geschieht typischerweise, wenn die Abfrage GROUP BY- und ORDER BY-Klauseln enthält, die Spalten unterschiedlich auflisten.

Using where

Mit einer WHERE-Klausel wird festgelegt, welche Datensätze mit der nächsten Tabelle verglichen oder an den Client gesendet werden. Sofern Sie nicht gezielt alle Datensätze aus der Tabelle abrufen oder untersuchen wollen, haben Sie in der Abfrage einen Fehler gemacht, wenn der Wert Extra nicht Using where ist und ALL oder index als Join-Typ für die Tabelle angegeben ist.

Wollen Sie Ihre Abfragen so schnell wie möglich machen, dann sollten Sie nach den Extra-Werten Using filesort und Using temporary suchen.

Using sort_union(…), Using union(…), Using intersect(…)

Diese Werte geben an, wie Indexscans für den Join-Typ index_merge zusammengefasst werden. Weitere Informationen finden Sie in Abschnitt 7.2.6, „Optimierung durch Indexverschmelzung“.

Using index for group-by

Ähnlich wie die Tabellenzugriffsmethode Using index gibt Using index for group-by an, dass MySQL einen Index gefunden hat, der zum Abrufen aller Datensätze einer GROUP BY- oder DISTINCT-Abfrage ohne zusätzlichen Festplattenzugriff auf die eigentliche Tabelle verwendet werden kann. Außerdem wird der Index auf die effizienteste Art und Weise verwendet, sodass für jede Gruppe nur ein paar wenige Indexeinträge gelesen werden. Detaillierte Informationen finden Sie in Abschnitt 7.2.13, „GROUP BY-Optimierung“.

Using where with pushed condition

Dieses Element ist ausschließlich für NDB Cluster-Tabellen verfügbar. Es bedeutet, dass MySQL Cluster einen Bedingungs-Pushdown verwendet, um die Effizienz eines direkten Vergleichs (=) zwischen einer nichtindizierten Spalte und einer Konstanten zu steigern. In solchen Fällen wird die Bedingung in den Datenknoten des Clusters „eingekellert“, wo sie dann in allen Partitionen gleichzeitig ausgewertet wird. Hierdurch wird der Versand unpassender Datensätze über das Netzwerk vermieden, und die entsprechenden Abfragen werden um den Faktor 5 bis 10 im Vergleich zu Fällen beschleunigt, in denen ein Bedingungs-Pushdown hätte verwendet werden können, aber nicht verwendet wurde.

Angenommen, eine Cluster-Tabelle sei wie folgt definiert:

CREATE TABLE t1 (
    a INT, 
    b INT, 
    KEY(a)
) ENGINE=NDBCLUSTER;

In diesem Fall kann ein Bedingungs-Pushdown bei einer Abfrage wie der folgenden verwendet werden:

SELECT a,b FROM t1 WHERE b = 10;

Die Ausgabe von EXPLAIN SELECT sieht dann wie folgt aus:

mysql> EXPLAIN SELECT a,b FROM t1 WHERE b = 10\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10
        Extra: Using where with pushed condition

Ein Bedingungs-Pushdown kann nicht mit einer der beiden folgenden Abfragen verwendet werden:

SELECT a,b FROM t1 WHERE a = 10;
SELECT a,b FROM t1 WHERE b + 1 = 10;

Bezüglich der ersten dieser zwei Abfragen ist der Bedingungs-Pushdown nicht anwendbar, weil in der Spalte a ein Index vorhanden ist. Im Falle der zweiten Abfrage kann ein Bedingungs-Pushdown nicht verwendet werden, weil der Vergleich unter Berücksichtigung der nichtindizierten Spalte b ein indirekter Vergleich ist. (Er wäre allerdings gültig, wenn Sie in der WHERE-Klausel b + 1 = 10 auf b = 9 reduzieren würden.)

Allerdings kann ein Bedingungs-Pushdown auch verwendet werden, wenn eine indizierte Spalte unter Verwendung eines der Operatoren > oder < mit einer Konstanten verglichen wird:

mysql> EXPLAIN SELECT a,b FROM t1 WHERE a<2\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
         type: range
possible_keys: a
          key: a
      key_len: 5
          ref: NULL
         rows: 2
        Extra: Using where with pushed condition

Merken Sie sich in Bezug auf einen Bedingungs-Pushdown Folgendes: