Abfrage beschleunigen

[Jürgen]

Hallo Forum,
ich habe eine Datenbank mit 160.000 - 200.000 Artikel, in welcher ich suchen möchte.
Die Abfrage ist mir viel zu langsam.
Wie kann ich diese Beschleunigen?
Durch anderen Index oder...

Hier meine Abfrage:
SELECT A.article_id, A.merchant_id, A.tax_class_id, A.url_pic, A.flg_new, AD.name, AD.description, AP.price, AP.list_price, M.name, AAD.asb_name, AAD.asb_name, AAD.info_url, AAD.logo_url, AAD.alt_text
FROM
ARTICLE AS A
INNER JOIN ARTICLE_DESCRIPTION AS AD ON A.article_id=AD.article_id AND A.merchant_id=AD.merchant_id AND A.shop_id=AD.shop_id
INNER JOIN ARTICLE_PRICE AS AP ON A.article_id=AP.article_id AND A.merchant_id=AP.merchant_id AND A.shop_id=AP.shop_id
INNER JOIN MANUFACTURE AS M ON A.manufacture_id=M.manufacture_id AND A.shop_id=M.shop_id
INNER JOIN ARTICLE_ASB_DESCRIPTION AS AAD ON A.flg_asb=AAD.flg_asb AND A.shop_id=AAD.shop_id
WHERE
A.shop_id=1 AND A.flg_is_active=1 AND AD.name like '%wort%' AND AD.country_code_id=2
AND AP.amount=0 AND AP.customer_group_id=0
ORDER BY A.mass_article, AD.name

In den betreffenden Tabellen habe ich folgende Indexe erstellt:
ARTICLE
-------
  PRIMARY KEY  (article\_id,merchant\_id,shop\_id),
  KEY parent\_article\_id (parent\_article\_id),
  KEY tax\_class\_id (tax\_class\_id),
  KEY manufacture\_id (manufacture\_id),
  KEY article\_number (article\_number),
  KEY flg\_new (flg\_new),
  KEY flg\_bargain (flg\_bargain),
  KEY flg\_is\_active (flg\_is\_active),
  KEY flg\_asb (flg\_asb),
  KEY insert\_date (insert\_date)

ARTICLE_DESCRIPTION
-------------------
  PRIMARY KEY  (article\_id,country\_code\_id,merchant\_id,shop\_id)

MANUFACTURE
-----------
  PRIMARY KEY  (manufacture\_id,shop\_id),
  KEY done (done),
  KEY name (name)

ARTICLE_ASB_DESCRIPTION
-----------------------
  PRIMARY KEY  (flg\_asb,shop\_id)

Hat jemand einen Tipp für mich?

Im voraus Danke

Jürgen

[Peter]

PRIMARY KEY  (article\_id,merchant\_id,shop\_id),
  KEY parent\_article\_id (parent\_article\_id),
  KEY tax\_class\_id (tax\_class\_id),
  KEY manufacture\_id (manufacture\_id),
  KEY article\_number (article\_number),
  KEY flg\_new (flg\_new),
  KEY flg\_bargain (flg\_bargain),
  KEY flg\_is\_active (flg\_is\_active),
  KEY flg\_asb (flg\_asb),
  KEY insert\_date (insert\_date)

HI!

Ohne mir dein Query lange anzuschauen bzw. das getan zu haben und dein DBMS zu kennen. Hier mal ein Tipp aus meiner persönlichen "Erfahrungskiste". Du verwendest relativ viele Flags (ich vermute mal bit-Felder).

Ein Index auf diese Felder bringt eigentlich gar nichts weil viele DBMS-Systeme diesen Index nicht benutzen werden sondern immmer auf einen TableScan zurück greifen werden.

MFG
Peter

[Jürgen]

Ohne mir dein Query lange anzuschauen bzw. das getan zu haben und dein DBMS zu kennen. Hier mal ein Tipp aus meiner persönlichen "Erfahrungskiste". Du verwendest relativ viele Flags (ich vermute mal bit-Felder).

Ein Index auf diese Felder bringt eigentlich gar nichts weil viele DBMS-Systeme diesen Index nicht benutzen werden sondern immmer auf einen TableScan zurück greifen werden.

MFG
Peter

Hallo Peter,
Die verwendete Datenbank ist Mysql.
Die Felder mit den Flags sind im Prinzip ja/nein Felder mit Inhalt 0 oder 1.
Aber ich denke das die nicht die Abfrage ausbremsen oder??

[Peter]

Hallo Peter,
Die verwendete Datenbank ist Mysql.
Die Felder mit den Flags sind im Prinzip ja/nein Felder mit Inhalt 0 oder 1.
Aber ich denke das die nicht die Abfrage ausbremsen oder??

HI!

Also wie gesagt, der Typ spielt hier ein besondere Rolle ob der Index verwendet wird oder nicht. Sollte ich recht behalten können diese vielen TableScans schon einiges an Performance kosten.

Peter

[Jürgen]

Also wie gesagt, der Typ spielt hier ein besondere Rolle ob der Index verwendet wird oder nicht. Sollte ich recht behalten können diese vielen TableScans schon einiges an Performance kosten.

Hallo Peter,
die Felder sind als int(11) angelegt.
Ist das ok?
Oder sollte ich den Typ ändern, wenn ja in welches Format.

[Peter]

die Felder sind als int(11) angelegt.
Ist das ok?
Oder sollte ich den Typ ändern, wenn ja in welches Format.

OK, mit MySQL kenne ich mich weniger aus, deswegen verstehe ich auch nicht warum man bei nem int ne Feld/Typ-Größe mitgeben kann. ich verstehe aber auch nicht warum es den zum einem ein int ist (weil ja eigentlich nur 2 Zustände 1 & 0 gespeichert werden also im Prinzip ein bit) und zum anderen warum int(11) ist ja nicht so toll im Design.

Ich habe keine Ahnung ob ich etz Schwachsinn erzähle aber eine alternative wäre die Flags gegen DateTime zu tauschen. Dann klappts auch mit dem Index besser und du erkennst zu dem auch wann das Flag gesetzt wurde (sollte es mal eine Rolle spielen). Also im Prinzip suchst dann nach den Feldern die nicht null sind null bedeutet dann nicht gesetzt und ein vorhandenes Datum das es eben gesetzt ist. Wie gesagt der Tipp bezieht sich auf den Index ob man einfach das Query optimieren könnte weiß ich nicht.

Peter

PS: Was man noch ändern könnte, hat aber auch wieder mit dem Index zu tun: ...1 AND AD.name like '%wort%' AND AD...

Ich weiß nicht wie MySQL sich hier verhält (TableScan oder Index) wenn er nach nem StringPattern suchen soll. Es gibt aber (zumindest in MSSQL) die Möglichkeit einen Index auf Funktionen zu legen!!!

[Nick]

Hallo Forum,
ich habe eine Datenbank mit 160.000 - 200.000 Artikel, in welcher ich suchen möchte.
Die Abfrage ist mir viel zu langsam.
Wie kann ich diese Beschleunigen?
Durch anderen Index oder...

Hier meine Abfrage:
SELECT A.article_id, A.merchant_id, A.tax_class_id, A.url_pic, [...]

Hast Du mal ein EXPLAIN (oder was immer Dein DBMS da bietet) über die Abfrage laufen lassen, um die Meinung Deines DBMS zur Query zu sehen?

Nick

[Jürgen]

Hallo Nick,

Danke für deine schnelle Antwort.
Ich verwende Mysql 4.1.21
Leider kenne ich mich mit Explain nicht aus und kann daher mit der Antwort nicht viel anfangen.
Das Ergebnis würde ich gerne posten aber ich weis nicht wie ich eine html-Tabelle posten kann.