slow_querys

[marc75]

Hallo Leute,

ich bräuchte mal kurz ein Tipp. Folgende Abfrage habe ich in einem PHP Script:

mysql_query("SELECT
             cat_id
        FROM  product_knoten
        WHERE product_id = ".$id.""); 

Die DB Strukur sieht dazu so aus:

CREATE TABLE IF NOT EXISTS `product_knoten` (
  `cat_id` int(11) unsigned NOT NULL DEFAULT '0',
  `product_id` int(11) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`cat_id`,`product_id`)
) ENGINE=MyISAM;

Jetzt stellst sich mir die Frage warum, die SQL Anweisung immer in den slow_query_log landet.

[Abraxax]

Leg mal noch einen Index auf product_id.

[marc75]

ok, dann erscheint es nicht mehr in den Logs, ich dachte immer man soll eine Spalte nicht zweimal indizieren, auch wenn diese davon einmal in ein Doppel Index steckt.

[admin]

ist der PRIMARY KEY (`cat_id`,`product_id`) nicht automatisch INDEX ??
(BTW : beim Microsoft SQL Server ist das so ...)

[asp2php]

OffTopic:

---

Was soll der Unfug mit ."" am Ende? Du bist lange genug dabei, um zu wissen, dass das sinnfrei ist!

---

[marc75]

@asp2php
Das ist noch ein Relikt aus alten Zeiten, ich dacht nur ich sollte das jetzt mal wieder anfassen, damit es nicht mehr in den logs erscheint.

@bernie
eigentlich Ja und dazu ist Primary noch unique

[wahsaga]

ist der PRIMARY KEY (`cat_id`,`product_id`) nicht automatisch INDEX ??

Ja, aber der ist in diesem Falle aus zwei Spalten zusammengesetzt - und nur der Inhalt der zweiten Spalte taucht in der WHERE-Klausel auf.

MySQL kann Indices zum Suchen aber m.W. nur dann effizient nutzen, wenn das, wonach gesucht wird, am Anfang dessen steht, worauf der Index liegt.

Ist bei einer normalen Textspalte, auf der ein Index liegt, analog - bei der Suche mit LIKE 'abc%' hilft dir der Index noch, aber wenn du dann LIKE '%abc%' suchst, also irgendwo "mitten drin" im Spalteninhalt, dann bringt der Index da AFAIK wenig bis gar nichts mehr.

Kannst du mit einem Telefonbuch vergleichen - die Leute, deren Nachnamen [1] mit "Meier" beginnen (Meierhans, Meiermann, Meiergeier ...), findest du recht schnell - du fängst unter "M" zu suchen an, nimmst dir dann "Me" vor, usw.

Aber jetzt such mir mal aus dem Telefonbuch alle Leute raus, deren Name auf "mann" endet - das artet in Arbeit aus, weil du dir alle Einträge im kompletten Buch anschauen musst.


[1] Nachname wäre im Telefonbuch die "indizierte" Spalte. Gut, auch ein wenig gelogen, denn im Telefonbuch liegt eher eine Sortierung als eine Indizierung vor. Aber diese Sortierung hilft dir beim Suchen, bspw. eine binäre Suche kannst du darauf ganz leicht anwenden - Telefonbuch in der Mitte aufschlagen, liegt der Anfangsbuchstabe davor oder dahinter, usw. usf.
Und ein kleines bisschen hinken darf so ein Vergleich ja auch mal - aber das Prinzipielle an der Aussage wird wohl trotzdem deutlich.

[TBT]

Die product_id ist aber der ZWEITE Teil des Index, daher NICHT nutzbar.
Wenn der Index (product_id,cat_id) heißen würde, dann würde er den auch nutzen.

[Abraxax]

ist der PRIMARY KEY (`cat_id`,`product_id`) nicht automatisch INDEX ??

Ja. Das ist ein kombinierter Index. Wenn das WHERE nach cat_id oder cat_id+product_id geht, macht es kein Unterschied.

Hier will er aber auf den zweiten Teil des Index. Das geht so nicht (schnell genug).

EDIT:

---

Nett .... gleich dreimal der gleiche Inhalt als Antwort ...

---

[admin]

Super Jungs

[marc75]

@wahsaga
man könnte meinen du hast das hier schon mal gelesen: Telefonbuch Beispiel

@wegen meiner Frage:
So wie ihr das erklärt habt, macht das auch Sinn.

So lasse ich das jetzt
PRIMARY KEY (`cat_id`,`product_id`)
INDEX (`product_id`)

Damit funktionieren die Abfragen nach cat_id und product_id jetzt wunderbar.

[wahsaga]

@wahsaga
man könnte meinen du hast das hier schon mal gelesen: Telefonbuch Beispiel

Ehrlich gesagt, nein - aber es war halt die erste Analogie, die mir zum Thema einfiel.