Hallo,

wir haben hier ein Performanzproblem mit einer MySQL DB (Version 5.x,
SLES 10, 64bit).

Diese Abfrage

SELECT DISTINCT d.DOCID, p.PRODUCTNAME, d.MainCategory, d.SubCategory,
ifnull(os.os, ''), ifnull(emu.emulation, ''),
dl.LANGUAGE, d.title, d.version, d.releasedate, d.FirmwareRelease FROM
PRODUCTS p
JOIN DOCPRODUCTNAMES dp on p.PRODUCTNAME = dp.PRODUCTNAME
JOIN DOCUMENTS d on d.DOCID = dp.DOCID
JOIN DOCLANGUAGES dl on dl.DOCID = d.DOCID
LEFT OUTER JOIN DOCOS os on os.DOCID = d.DOCID
LEFT OUTER JOIN DOCEMULATIONS emu on emu.DOCID = d.DOCID
ORDER BY p.PRODUCTNAME, d.MainCategory LIMIT 0, 50

läuft quälend langsam. Die vielen joins sind wohl das Problem.

Hat jemand eine Idee wie man das beschleunigen kann ?

Wir haben hier schon überlegt einige Tabellen zu denomalisieren, haben
jedoch sorgen viel zu viel Plattenplatz zu benötigen.

Vielen Dank schon mal
Gruß
Hans

Hans Müller schrieb:
> Hallo,
>
> wir haben hier ein Performanzproblem mit einer MySQL DB (Version 5.x,
> SLES 10, 64bit).
>
> Diese Abfrage
>
> SELECT DISTINCT d.DOCID, p.PRODUCTNAME, d.MainCategory, d.SubCategory,
> ifnull(os.os, ''), ifnull(emu.emulation, ''),
> dl.LANGUAGE, d.title, d.version, d.releasedate, d.FirmwareRelease FROM
> PRODUCTS p
> JOIN DOCPRODUCTNAMES dp on p.PRODUCTNAME = dp.PRODUCTNAME
> JOIN DOCUMENTS d on d.DOCID = dp.DOCID
> JOIN DOCLANGUAGES dl on dl.DOCID = d.DOCID
> LEFT OUTER JOIN DOCOS os on os.DOCID = d.DOCID
> LEFT OUTER JOIN DOCEMULATIONS emu on emu.DOCID = d.DOCID
> ORDER BY p.PRODUCTNAME, d.MainCategory LIMIT 0, 50
>
> läuft quälend langsam. Die vielen joins sind wohl das Problem.
>
> Hat jemand eine Idee wie man das beschleunigen kann ?
>
EXPLAIN?

Hier das Ergebnis vom Explain (sieht für mein nicht so SQL trainiertes
Auge) ganz Ok aus, alle Spalten haben einen Index

1, 'SIMPLE', 'a', 'ref', 'ID_ACCESS,ID_ACCESS2', 'ID_ACCESS2', '771',
'const', 379, 'Using where; Using temporary; Using filesort'
1, 'SIMPLE', 'd', 'ref', 'PRIMARY,ID_DOCID,ID_DOCID8', 'ID_DOCID8', '5',
'offline.a.CODE', 19, 'Using where'
1, 'SIMPLE', 'os', 'ref', 'ID_DOCOS', 'ID_DOCOS', '5',
'offline.d.DOCID', 11, ''
1, 'SIMPLE', 'emu', 'ref', 'ID_EMID', 'ID_EMID', '5', 'offline.d.DOCID',
11, ''
1, 'SIMPLE', 'dl', 'ref', 'ID_LANID', 'ID_LANID', '5',
'offline.d.DOCID', 11, 'Using where'
1, 'SIMPLE', 'dp', 'ref', 'ID_PRODUCTNAMES,ID_PRODUCTNAMES2',
'ID_PRODUCTNAMES', '5', 'offline.dl.DOCID', 19, 'Using where'
1, 'SIMPLE', 'p', 'ref', 'ID_PRODUCTS4', 'ID_PRODUCTS4', '387',
'offline.dp.PRODUCTNAME', 15, 'Using where; Using index'



Gruß Hans

Am Mittwoch, den 28.11.2007, 16:58 +0100 schrieb Hans Müller:
> 1, 'SIMPLE', 'a', 'ref', 'ID_ACCESS,ID_ACCESS2', 'ID_ACCESS2', '771',
> 'const', 379, 'Using where; Using temporary; Using filesort'

Wie viel (Zeilen) wird da für den ORDER BY sortiert?

Gruß,
Joachim

Am Mittwoch, den 28.11.2007, 16:25 +0100 schrieb Hans Müller:
> läuft quälend langsam. Die vielen joins sind wohl das Problem.

Nein. Mein Tip wäre der ORDER BY.

Mal probeweise ohne selbigen ausführen.

> Hat jemand eine Idee wie man das beschleunigen kann ?

Falls die Abfrage unsortiert schnell ist,

http://dev.mysql.com/doc/refman/5.1/de/order-by-optimization .html

lesen und anwenden (d.h. z.Bsp. p.produktname indizieren und
d.MainCategory aus dem ORDER BY rausnehmen).

Gruß,
Joachim

Hans Müller schrieb:
> Hier das Ergebnis vom Explain (sieht für mein nicht so SQL trainiertes
> Auge) ganz Ok aus, alle Spalten haben einen Index
>
> 1, 'SIMPLE', 'a', 'ref', 'ID_ACCESS,ID_ACCESS2', 'ID_ACCESS2', '771',
> 'const', 379, 'Using where; Using temporary; Using filesort'
> 1, 'SIMPLE', 'd', 'ref', 'PRIMARY,ID_DOCID,ID_DOCID8', 'ID_DOCID8', '5',
> 'offline.a.CODE', 19, 'Using where'
> 1, 'SIMPLE', 'os', 'ref', 'ID_DOCOS', 'ID_DOCOS', '5',
> 'offline.d.DOCID', 11, ''
> 1, 'SIMPLE', 'emu', 'ref', 'ID_EMID', 'ID_EMID', '5', 'offline.d.DOCID',
> 11, ''
> 1, 'SIMPLE', 'dl', 'ref', 'ID_LANID', 'ID_LANID', '5',
> 'offline.d.DOCID', 11, 'Using where'
> 1, 'SIMPLE', 'dp', 'ref', 'ID_PRODUCTNAMES,ID_PRODUCTNAMES2',
> 'ID_PRODUCTNAMES', '5', 'offline.dl.DOCID', 19, 'Using where'
> 1, 'SIMPLE', 'p', 'ref', 'ID_PRODUCTS4', 'ID_PRODUCTS4', '387',
> 'offline.dp.PRODUCTNAME', 15, 'Using where; Using index'

Dein Join macht 379*19*11*11*11*19*15 vergleiche was auf etwa 2731591335
Operationen hinausläuft. Also gar kein Wunder das dein Select langsam
ist. Der explain ist also ganz und gar nicht OK.

Deine 'treibende' Tabelle ist a im Hinblick auf eine evtl. greifende
ORDER BY-Optimierung ist das schlecht.

Da du auf nach PRODUCTNAME ordnest solltest du versuchen diese Tabelle
als erster in den explain zu bekommen, einen subselect zu machen oder
eine temporäre Tabelle zu nutzen um die Ergebnissmenge schon vor den
Joins auf 50 sets zu reduzieren.

Was ich nicht verstehe, du hast im explain eine Tabelle a welches im
Select nicht vorkommt!
Du hast zu jedem Produkt. 11 Dokumentationen für 11 verschiedene Länder.
Wobei man in jedem dieser Länder 11 verschiedene Sprachen spricht?
Komisch. Wer schreibt denn bitte 1331 Dokumentationen zu einem Produkt?
Design Kaput?

Wenn du willst das man Dir hilft. Dann solltest du uns helfen Dir zu
helfen. Dazu gehören lesbare formatierte Ausgaben und Statements.
Ausgaben werden lesbar wenn du '\G' statt ';' benutzt.
Außerdem solltest du immer den explain zu dem Select posten (Und keinen
anderen). Die angelegten Indizes, und die Create Tables sind meist auch
ganz nützlich. Raten macht vielleicht in einem Quiz spaß hier leider nicht.

Hallo Wissende,

herzlichen Dank für eure Mühen, die hier bekommenen Anregungen haben zu einer
Abfragezeit unter einer Sekunde geührt, was nun Ok ist!

Gruß
Hans

Am Freitag, den 30.11.2007, 11:25 +0100 schrieb Hans Müller:
> herzlichen Dank für eure Mühen, die hier bekommenen Anregungen haben =
zu einer
> Abfragezeit unter einer Sekunde geührt, was nun Ok ist!

Es gibt wenig, was länger dauern muss :)

Aber kannst Du noch eine kurze Zusammenfassung der Lösung posten, die
Einzelheiten würden mich schon interessieren.

Thx,
Joachim