Powolne przeglądanie produktów Opcje

[Walian]

Witam,

Pracuję nad pewnym serwisem internetowym (niestety nie wolno mi podawać nazwy ani adresu), który zaczyna już dość mocno zwalniać. W chwili obecnej problem stanowią dwie tabele:
- tabela produktów - MyISAM, ponad 700 tyś rekordów, ponad 180 MB.
- tabela ofert do produktów - MyISAM, ponad 1 125 000 rekordów, ponad 230 MB.

Do rzeczy - problem stanowi już samo przeglądanie produktów.

[SQL] pobierz, plaintext 
SELECT 
	SQL_NO_CACHE 
	SQL_CALC_FOUND_ROWS 
	`p`.`produkt_id`,
	`p`.`name`,
	`p`.`katalog`,
	`p`.`pod_katalog`,
	`p`.`category_id`,
	`o`.`user_id`,
	`o`.`cena`,
	`o`.`id` AS `id_offer` 
FROM 
	`produkty` `p` 
INNER JOIN 
	`oferty` `o` 
ON 
	`o`.`produkt_id`=`p`.`produkt_id` 
LEFT JOIN 
	`uzytkownicy` `u` 
ON 
	`u`.`user_id`=`o`.`user_id` 
WHERE 
		`u`.`aktywny`=1 ; Tu waskie gardlo...
		; W chwili obecnej wszyscy maja "1", ale TO sie kiedys zmieni...
	AND 
		`p`.`category_id` IN (tutaj 176 numerow (cale drzewko) kategorii) 
	AND ; Od tego momentu rozne filtry:
		`o`.`cena` BETWEEN 1 AND 99999 
ORDER BY 
	`p`.`name` ASC ; Zamiast tego moze sie pojawic sortowanie wg ceny
LIMIT 0,20
[SQL] pobierz, plaintext 

20 rows in set (9.70 sec)

Bez SQL_CALC_FOUND_ROWS:

20 rows in set (6.63 sec)

To samo zapytanie, ale bez wyciągania danych - zamiast tego COUNT(*):

20 rows in set (6.71 sec)

Teraz wracając do początku:
Bez "`u`.`aktywny`=1":

20 rows in set (1.86 sec)

Bez "`u`.`aktywny`=1" oraz bez "ORDER BY `p`.`name` ASC":

20 rows in set (1.16 sec)

Bez "`u`.`aktywny`=1" oraz bez "`o`.`cena` BETWEEN 1 AND 99999" oraz bez "ORDER BY `p`.`name` ASC":

20 rows in set (1.07 sec)

Ostatnie zapytanie, ale bez SQL_CALC_FOUND_ROWS:

20 rows in set (0.00 sec)

Serwis stoi na serwerze dedykowanym...

Jak przyspieszyć to zapytanie? Nie mogę zrezygnować z tych warunków WHERE, ale może da radę jakoś inaczej zapytanie skonstruować?
Przejście na InnoDB pomoże czy rozwiązania trzeba szukać gdzie indziej?

[Walian]

Wprowadziłem nowe zapytanie + nowy indeks i wydaje się działać szybciej.
Na najbardziej zapełnionych drzewkach kategorii czas to ok. 2.5s, na tych mniejszych nawet 0.15s.
No ale wątpię by to był szczyt optymalizacji, także jak ktoś ma jeszcze jakiś pomysł to niech śmiało nawija (IMG:style_emoticons/default/smile.gif)

A czy jeśli wszystkie trzy tabele przerzucę na InnoDB to zapytanie przyspieszy?

Zrób sobie jakiegoś trigera i pomocnicze pole w tabelce z ofertami, tak żeby wyeliminować to złączenie.

Chodzi Ci o to, by zmieniać status ofertom, zamiast użytkownikom - jeden czasochłonny zapis, zamiast wielu czasochłonnych odczytów ?