nicht angemeldet
mysql EXPLAIN, und dann?
MudGuardHi,
ich habe auf eine Query, die mir etwas lange dauert, einen EXPLAIN angewendet und erhalte folgendes Ergebnis (ich teile die Tabelle mal in 2 Teile, damit es lesbar bleibt):
id select_type table type possible_keys
1 PRIMARY b1 ALL tableID
2 DEPENDENT SUBQUERY b2 ALL NULL
key key_len ref rows Extra
NULL NULL NULL 46833 Using where
NULL NULL NULL 46833 Using where
Frage: Warum wird der "possible key" tableID nicht genutzt? Die Spalte "tableID" hat einen Index.
Lukas
akzeptierte Antworten
mysql EXPLAIN, und dann?
Rolf b
Bewertung: +1, 1 Stimme
-
Hi,
id select_type table type possible_keys 1 PRIMARY b1 ALL tableID 2 DEPENDENT SUBQUERY b2 ALL NULL key key_len ref rows Extra NULL NULL NULL 46833 Using where NULL NULL NULL 46833 Using whereFrage: Warum wird der "possible key" tableID nicht genutzt? Die Spalte "tableID" hat einen Index.
Wer soll das ohne Kenntnis der Query, der Tabellenstruktur, der Datenmengen, der MySql-Version, der MySQL-Engine (Inno, Isam, ...) usw. beantworten?
cu,
Andreas a/k/a MudGuard-
Wer soll das ohne Kenntnis der Query, der Tabellenstruktur, der Datenmengen, der MySql-Version, der MySQL-Engine (Inno, Isam, ...) usw. beantworten?
SELECT ASK "Wer soll das ohne Kenntnis der Query, der Tabellenstruktur, der Datenmengen, der MySql-Version, der MySQL-Engine (Inno, Isam, ...) usw. beantworten?" FROM `live`Antwort:
wer Kristallkugel 1 row in 0.0001 s
-
-
Ergänzend zu den Flames der anderen kann ich dazu sagen, dass es für eine Datenbank nicht immer effizient ist, den Index zu nutzen.
Beispiel 1: Wenn der Index, der die tableId enthält, kein Clustered Index (PRIMARY KEY in InnoDB) ist, dann ist die physikalische Reihenfolge der Sätze in der Table nicht zwingend identisch mit der ID-Reihenfolge, und wenn man dann in Indexreihenfolge liest, muss der Server in der Table-Datei hin- und herspringen. Falls Du MyISAM nutzt: Da gibt es keine Clustered Indexe.
Beispiel 2: Wenn deine Where-Bedingung Felder außerhalb des Index abfragt, muss ohnehin die ganze Table durchgelesen werden. Dann nützt der Index nichts.
Für genauere Antworten braucht es - wie schon von anderen gesagt, mehr Informationen. Table+Index Design, Database Engine, Query.
Rolf
-
Hallo Rof,
Ergänzend zu den Flames
Danke.
Beispiel 1: Wenn der Index, der die tableId enthält, kein Clustered Index (PRIMARY KEY in InnoDB) ist, dann ist die physikalische Reihenfolge der Sätze in der Table nicht zwingend identisch mit der ID-Reihenfolge, und wenn man dann in Indexreihenfolge liest, muss der Server in der Table-Datei hin- und herspringen. Falls Du MyISAM nutzt: Da gibt es keine Clustered Indexe.
Genau darum ging es mir. Um die Frage und ggf. ein Beispiel, warum mysql einen vorhandenen Index ungenutzt läßt.
Beispiel 2: Wenn deine Where-Bedingung Felder außerhalb des Index abfragt, muss ohnehin die ganze Table durchgelesen werden. Dann nützt der Index nichts.
Ok. Verstehe.
Für genauere Antworten braucht es - wie schon von anderen gesagt, mehr Informationen. Table+Index Design, Database Engine, Query.
Deine Antwort war exakt das, was mir zum gegenwärtigen Zeitpunkt völlig ausreicht. Das kann sich ändern, aber momentan war mir erstmal dieses (für mich) Paradoxon wichtig, aufzuklären. Deine Beispiele waren hierfür ein guter Einstieg für mich.
Dank Dir.
Lukas
-