nicht angemeldet
dieser ganz bestimmt nicht. Wenn doch, überdenke Deine Bezeichner!
Mein Hoster meinte, dass durch diesen Query der mySQL-Server massiv belegt wurde, wodurch die Prozesse hängen geblieben sind und ich keine neuen Verbindungen herstellen konnte.
In einem Blog habe ich gelesen, dass SQL_CALC_FOUND_ROWS dazu geführt hat, dass bei demjenigen ebenfalls der SQL-Server in unregelmäßigen Abständen abgestürzt ist.
-- aus welchen Tabellen sind col2 und col3?
Die Spalten kommen aus den diversen Tabellen tab1 bis tab4. Eigentlich lese ich noch weitere Spalten aus, aber ich dachte die 3 reichen vorerst um das Problem zu schildern.
LEFT JOIN tab2 ON tab1.id=tab2.tab1_id
LEFT JOIN tab3 ON tab2.id=tab3.tab2_id
LEFT JOIN tab4 ON tab3.id=tab4.tab3_id-- warum dreimal LEFT JOIN? Alle aufeinander aufbauend. Da gibt es keine
-- Chance, die Auswertungsreihenfolge umzustellen. Bist Du Dir ganz sicher, -- dass Du keine INNER JOINs verwenden kannst?
INNER JOINS funktionieren auch, allerdings habe ich keinen Unterschied (zumindest bzgl Geschwindigkeit) feststellen können.
Bezüglich der Auswertungsreihenfolge noch einmal den richtigen Query:
INNER JOIN tab2 ON tab1.id=tab2.tab1_id
INNER JOIN tab3 ON tab1.time=tab3.time
INNER JOIN tab4 ON tab1.group=tab4.id
WHERE tab1.col1 LIKE 'foo'
-- ist der Mustervergleich wirklich nötig. Reichte nicht das Gleichheitszeichen?
Zur Zeit leider ja, da eigentlich mit '%foo%' verglichen wird. Das ist vermutlich der Performance-Killer. Das könnte ich vermutlich lösen, indem ich einen eigenen Index aufbaue oder den Volltext-Index nutze.
Struppi