Abfrage bleibt stehen bzw. braucht sehr lange...

Hallo hier,

ich habe ein Problem! Folgende Abfrage braucht sehr lange und bringt
meinen mysql-server zu 100% Auslastung.

Wie kann ich diese Abfrage weiter verbessern?

SELECT A.id, A.Artikel, A.bezeichnung1, A.Bezeichnung2,
AArtikelgruppe, A.verkaufspreis1, A.Memotext, A.Mengeneinheit,
BBezeichnung, bilder.kleine_bilder
FROM artikelstamm AS A, artikelgruppenliste AS B
LEFT JOIN bilder ON A.Artikel =3D bilder.artikel_nr
WHERE A.Artikelgruppe =3D B.AGR
AND (
Abezeichnung1 LIKE '%töpsel%'
OR A.Bezeichnung2 LIKE '%töpsel%'
OR A.Artikel LIKE 'töpsel%'
OR A.memotext LIKE '%töpsel%'
OR A.matchcode LIKE '%töpsel%'
)
OR (
Abezeichnung1 LIKE '%poly%'
OR A.Bezeichnung2 LIKE '%poly%'
OR A.Artikel LIKE 'poly%'
OR A.memotext LIKE '%poly%'
OR A.matchcode LIKE '%poly%'
OR B.bezeichnung LIKE 'poly%'
)
ORDER BY A.bezeichnung1
LIMIT 0 , 31


Danke,
Veit.

Re: Abfrage bleibt stehen bzw. braucht sehr lange...

x82@gmx.net schrieb:

Wenn Deine Eltern Dich wirklich x82 genannt haben: Mein Beileid. Sonst:
Hier sind Realnamen erwünscht. Viele Leute halten es für unhöflich, wenn
sich jemand hinter einem Nickname versteckt und ignorieren solche Postings.

> ich habe ein Problem! Folgende Abfrage braucht sehr lange und bringt
> meinen mysql-server zu 100% Auslastung.
>
> Wie kann ich diese Abfrage weiter verbessern?
>

Mit den Informationen, die Du lieferst, kann Dir das niemand sagen.
Warum postest Du nicht die Ausgaben von
SHOW CREATE TABLE
und
EXPLAIN

> SELECT A.id, A.Artikel, A.bezeichnung1, A.Bezeichnung2,
> A.Artikelgruppe, A.verkaufspreis1, A.Memotext, A.Mengeneinheit,
> B.Bezeichnung, bilder.kleine_bilder
> FROM artikelstamm AS A, artikelgruppenliste AS B
> LEFT JOIN bilder ON A.Artikel = bilder.artikel_nr
> WHERE A.Artikelgruppe = B.AGR
> AND (
> A.bezeichnung1 LIKE '%töpsel%'
> OR A.Bezeichnung2 LIKE '%töpsel%'
> OR A.Artikel LIKE 'töpsel%'
> OR A.memotext LIKE '%töpsel%'
> OR A.matchcode LIKE '%töpsel%'

Solche Abfragen lassen sich gar nicht optimieren: bei % am Anfang eines
LIKE benutzt MySQL keinen Index (wie Du ja sicherlich weißt, weil Du die
Dokumentation gelesen hast, oder?). Wenn Du wirklich meinst, solche
Suchen zu brauchen, dann definiere einen Volltext-Index auf die Spalten.

An Deiner Stelle würde ich den "Komfort" abspecken und verlangen, dass
die Anwender das Gesuchte in dem Feld eintippen, in dem sie es vermuten.
Wahlloses Suchen - hier sind schon Leute aufgeschlagen, die im PLZ-Feld
nach dem Artikelnamen geforscht haben, nur um sicherzugehen - bringen
außer zu vielen sinnlosen Treffern gar nichts. Siehe Amazon.

Re: Abfrage bleibt stehen bzw. braucht sehr lange...

Danke für die Antwort.

On 14 Jun., 12:43, Christian Kirsch wrote:
> x...@gmx.net schrieb:
>
> Wenn Deine Eltern Dich wirklich x82 genannt haben: Mein Beileid. Sonst:
> Hier sind Realnamen erwünscht. Viele Leute halten es für unhöflich,=
wenn
> sich jemand hinter einem Nickname versteckt und ignorieren solche Posting=
s
Danke fuer den Tip. Nur keine Ahnung wie ich bei google den Namen vor
die Emailadresse bekommen.
(ich arbeite dran)

> > ich habe ein Problem! Folgende Abfrage braucht sehr lange und bringt
> > meinen mysql-server zu 100% Auslastung.
>
> > Wie kann ich diese Abfrage weiter verbessern?
>
> Mit den Informationen, die Du lieferst, kann Dir das niemand sagen.
> Warum postest Du nicht die Ausgaben von
> SHOW CREATE TABLE
> und
> EXPLAIN
Muss ich noch machen.


> > SELECT A.id, A.Artikel, A.bezeichnung1, A.Bezeichnung2,
> > A.Artikelgruppe, A.verkaufspreis1, A.Memotext, A.Mengeneinheit,
> > B.Bezeichnung, bilder.kleine_bilder
> > FROM artikelstamm AS A, artikelgruppenliste AS B
> > LEFT JOIN bilder ON A.Artikel =3D bilder.artikel_nr
> > WHERE A.Artikelgruppe =3D B.AGR
> > AND (
> > A.bezeichnung1 LIKE '%töpsel%'
> > OR A.Bezeichnung2 LIKE '%töpsel%'
> > OR A.Artikel LIKE 'töpsel%'
> > OR A.memotext LIKE '%töpsel%'
> > OR A.matchcode LIKE '%töpsel%'
>
> Solche Abfragen lassen sich gar nicht optimieren: bei % am Anfang eines
> LIKE benutzt MySQL keinen Index (wie Du ja sicherlich weißt, weil Du die
> Dokumentation gelesen hast, oder?). Wenn Du wirklich meinst, solche
> Suchen zu brauchen, dann definiere einen Volltext-Index auf die Spalten.
Ja ich weiß. Ein Volltext-Index hatte ich schon erstellt.

> An Deiner Stelle würde ich den "Komfort" abspecken und verlangen, dass
> die Anwender das Gesuchte in dem Feld eintippen, in dem sie es vermuten.
> Wahlloses Suchen - hier sind schon Leute aufgeschlagen, die im PLZ-Feld
> nach dem Artikelnamen geforscht haben, nur um sicherzugehen - bringen
> außer zu vielen sinnlosen Treffern gar nichts. Siehe Amazon.
Darauf wird es auch hinauslaufen. Ich dachte es gibt noch etwas
verbesserungpotenzial.

Grüße
Veit

Re: Abfrage bleibt stehen bzw. braucht sehr lange...

Hier hab ich noch ein Abbild der Tabellen erstellt:

bilder:
id int(11) prim
artikel_nr varchar(50)
kleine_bilder text
grosse_bilder text

artikelstamm:
id mediumint(9) prim
Artikel varchar(50) index
bezeichnung1 varchar(50) index
Bezeichnung2 varchar(50) index
Artikelgruppe text
Mengeneinheit text
verkaufspreis1 float(10,2)
Memotext mediumtext index
stellplatz text
matchcode varchar(50) index


Ich hoffe das die Angaben weiterhelfen um mir weiterzuhelfen :)

Gruesse Veit

Re: Abfrage bleibt stehen bzw. braucht sehr lange...

Veit Berg schrieb:
> Hier hab ich noch ein Abbild der Tabellen erstellt:
>
> bilder:
> id int(11) prim
> artikel_nr varchar(50)
> kleine_bilder text
> grosse_bilder text
>
> artikelstamm:
> id mediumint(9) prim
> Artikel varchar(50) index
> bezeichnung1 varchar(50) index
> Bezeichnung2 varchar(50) index
> Artikelgruppe text
> Mengeneinheit text
> verkaufspreis1 float(10,2)
> Memotext mediumtext index
> stellplatz text
> matchcode varchar(50) index
>
>
> Ich hoffe das die Angaben weiterhelfen um mir weiterzuhelfen :)

Das ist nicht die Ausgabe von SHOW CREATE TABLE, oder? Und Du verrätst
auch nicht, was Dir EXPLAIN sagt.

Wie auch immer: Deine Indizes werden Dir aus den erwähnten Gründen (die
durch geschicktes Quoten jetzt nicht mehr zu sehen sind) einfach nicht
benutzt werden. Da kannst Du wenig dran ändern, wenn Du nicht Deinen
Benutzern den Pseudo-Komfort nimmst, nach beliebigen Zeichenketten in
beliebigen Feldern zu suchen. Wenn Du von ihnen erwartest, dass sie
wenigstens den Anfang des Wortes korrekt eingeben, dann kannst Du mit
LIKE "bla%"
statt
LIKE "%bla%"
suchen, und MySQL wird den Index auf dem Feld benutzen.

BTW: Den Preis als FLOAT zu definieren ist eine sehr, sehr schlecht
Idee. Auch verstehe ich nicht, warum eine Artikel*NR* ein Varchar sein
soll und warum man für eine Artikelgruppe oder eine Mengeneinheit ein
Feld braucht, das mehrere KByte aufnehmen kann. Beim Stellplatz mag das
ja angehen, wenn es so richtig super-duper kompliziert ist...

Hast Du eigentlich schon mal die Dokumentation zu MySQL gelesen, oder
wenigstens eine Einführung in SQL einschließlich Datentypen?

Re: Abfrage bleibt stehen bzw. braucht sehr lange...

On Thu, 14 Jun 2007 15:26:48 +0200 Christian Kirsch wrote:
> Auch verstehe ich nicht, warum eine Artikel*NR* ein Varchar sein
> soll

Das sollte man Hersteller fragen... eigentlich gibt es in meinem
Umfeld kaum jemanden, der _nicht_ alphanumerische Produktnummern
verwendet. Der Gipfel ist eine Firma, deren Produktnummern signifikante
Leerstellen enthalten (fuer die Datenbank ist das ja noch relativ egal,
aber wenn das Ding auf einer Webseite ausgegeben wird, sollte man das
besser vorher wissen).

> und warum man für eine Artikelgruppe oder eine Mengeneinheit ein Feld
> braucht, das mehrere KByte aufnehmen kann.

Das frage ichi mich allerdings auch. Beide Felder sind eigentlich
ideale Kandidaten fuer eine 1:n Verknuepfung.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan. Für verkrampfte Hasen, in allen Lagen!
(Sloganizer)

Re: Abfrage bleibt stehen bzw. braucht sehr lange...

Stefan Froehlich schrieb:
> On Thu, 14 Jun 2007 15:26:48 +0200 Christian Kirsch wrote:
>> Auch verstehe ich nicht, warum eine Artikel*NR* ein Varchar sein
>> soll
>
> Das sollte man Hersteller fragen... eigentlich gibt es in meinem
> Umfeld kaum jemanden, der _nicht_ alphanumerische Produktnummern
> verwendet. Der Gipfel ist eine Firma, deren Produktnummern signifikante
> Leerstellen enthalten (fuer die Datenbank ist das ja noch relativ egal,
> aber wenn das Ding auf einer Webseite ausgegeben wird, sollte man das
> besser vorher wissen).
>
>> und warum man für eine Artikelgruppe oder eine Mengeneinheit ein Feld
>> braucht, das mehrere KByte aufnehmen kann.
>
> Das frage ichi mich allerdings auch. Beide Felder sind eigentlich
> ideale Kandidaten fuer eine 1:n Verknuepfung.
Da die Tabellen von mir nicht selbst erstellt wurden werde ich diese mal
umstellen. Leider wie schon richtig erkannt muss die Produktnummer
ALPHA sein.

Danke fuer die Hilfe. Ich werde die suche etwas einfacher gestalten.

Bye
Veit