Witam, posaidam dwie tabele po około 2500 rekordów każda. Zapytanie wygląda tak:

[SQL] pobierz, plaintext 
SELECT 
g.id, g.title, g.data_add, img.ftp_file_id, img.ftp_file_extension 
FROM mpw_gallery g 
LEFT JOIN mpw_files img ON img.ftp_content_id = g.id 
WHERE g.atrybut = '562' AND lang = 'pl' 
ORDER BY g.title 
LIMIT 9, 9
[SQL] pobierz, plaintext 

I teraz aby wyświetlić 9 rekoród potrzebuje 23 sekund... to jest o wiele za długo! totalna masakra. Czy ktoś ma pomysł jak to przyspieszyć? Tak dla wyjaśnienia używam adodb oraz smartów.

Spróbuj założyć indeksy, jeśli wybierasz stosunkowa małą liczbe rekordów jednym zapytaniem, zrezygnuj z ORDER BY i sortowanie zrób na poziomie php'a.

pokaz strukture tabel (typy, indexy itp.) co jest relacjami wtedy bedzie mozna cos bardziej powiedziec jak zwiekszyc wydajnosc

I napisz czy sprawdzales ten czas bezposrednio na bazie czy poprzez swoja aplikacje (moze to w niej cos jest nie tak..), jesli nie sprawdzales czasu w samej bazie to zrob to.

Być może usuwając ORDER BY w zapytaniu faktycznie cos przyspieszysz wykonanie samego zapytania, jednak przerzucajac to na poziom php na pewno więcej stracisz niż zyskasz. Wszystkie (może prawie wszystkie) operacje jakie możliwe są na zrzucenie na system zarządzania bazą powinny być wykonane przez to właśnie oprogramowanie.

[SQL] pobierz, plaintext 
ORDER BY g.title
LIMIT 9, 9
[SQL] pobierz, plaintext 

Nie wiem jak dokładnie działa proces przetwarzania zapytań z LIMIT w MySQL'u ale podejrzewam ze w pierwszej fazie w przykładzie który tutaj mamy sortowany jest cały kursor z wynikiem. Jeśli jest to załóżmy hipotetycznie 25k rekordow, to proces sortowania zacząco wydłuży czas zwrócenia ostatczenego wyniku. Dlatego zasugerowałem żeby użyć sortowania po stronie php'a bo widziałem że z tego kursora wybierane są bardzo małe w porównaniu z kursoerm ilości rekordów.
Ale można tak sobie gdybać Dlatego moją sugestią jest sprawdzenie jak zachowa się zapytanie bez ORDER BY. Jest to jeden z hintów do tunningu zapytanka. jednak jak już było tutaj wspomniane bez dokładnych info. o strukturze tabeli i relacjach nie da się dać konkretnej odpowiedzi.

Jednak zgodze się z Tobą mhs w 100% że bardzo dobrą i wskazaną praktyką jest przerzucenie jak największej ilości operacji przetwarzania informacji na baze danych.

Synaps, wedlug mnie twoj pomysl jest pudlem, poniewaz bez ORDER BY zapytanie zwroci nie te rekordy, ktorych programista oczekuje, bowiem chodzi o to zeby posortowac (tutaj wedlug tytulu) i juz z posortowanej tabeli wybrac odpowiednie rekordy (dokladnie 9 rekordow od 10-go zaczynając), a NIE posortowac zwrócone rekordy. Tak więc w twoim rozwiazaniu należaloby pobrac wszystkei rekordy, co przy 25k (i nie tylko) kompletnie mija się z celem.

okazało się że jak zastąpie LEFT JOIN zapytaniem INNER JOIN skok wydajności jest z 21 sekund do ułamek sekund!
poprsotu trzeba siąść kiedyś i przeczytać w jaki sposób są realizowane te zapytania.

Moze napisze odnosnie tego co pisal @Synaps. Jesli chcesz stosowac sortowanie, to na tym polu definitywnie musi byc indeks (teoretycznie) duzo operacji jest pomijanych a wtedy limit jest tylko formalnoscia.