Lukas.: mysql EXPLAIN, und dann?

Hi,

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

  1. 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 where
    

    Frage: 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

    1. 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
      
  2. 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

    1. 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