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]

Ale jak niby taki cache zrobić? Nie widzę tu sensu, skoro najmniejsza zmiana w filtrze, przejście do innej kategorii, czy wyszukiwanie wg jakieś frazy zmienia już postać i ilość wyników. Po stronie serwera też nie ma sensu bo powstanie olbrzymia ilość plików cache. Jeśli do tego uwzględnić fakt, że ciągle są dodawane lub aktualizowane produkty to liczba "kombinacji" jest olbrzymia.

[SQL] pobierz, plaintext 
SHOW CREATE TABLE `uzytkownicy`;
CREATE TABLE `uzytkownicy` (
 `user_id` int(11) NOT NULL AUTO_INCREMENT,
 `aktywny` int(11) NOT NULL DEFAULT '1',
 PRIMARY KEY  (`user_id`),
 FULLTEXT KEY `nazwa_sklepu` (`nazwa_sklepu`),
 FULLTEXT KEY `city` (`city`)
) ENGINE=MyISAM AUTO_INCREMENT=100962 DEFAULT CHARSET=latin2 PACK_KEYS=0
-- Indeks na polu "aktywny" nic nie daje, bo w kazdym rekordzie jest "1", przynajmniej na razie
 
SHOW CREATE TABLE `produkty`;
CREATE TABLE `produkty` (
 `produkt_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
 `name` varchar(255) NOT NULL,
 `category_id` smallint(11) NOT NULL DEFAULT '0',
 `katalog` tinyint(4) NOT NULL DEFAULT '0',
 `pod_katalog` tinyint(4) NOT NULL DEFAULT '0',
 PRIMARY KEY  (`produkt_id`),
 KEY `products_name` (`active`,`name`),
 KEY `category_id` (`category_id`),
 FULLTEXT KEY `name` (`name`)
) ENGINE=MyISAM AUTO_INCREMENT=911612 DEFAULT CHARSET=utf8 PACK_KEYS=0
 
SHOW CREATE TABLE `oferty`;
CREATE TABLE `oferty` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `user_id` mediumint(10) NOT NULL DEFAULT '0',
 `cena` double(16,2) NOT NULL DEFAULT '0.00',
 `nazwa_prod` varchar(255) NOT NULL,
 `offer_id` bigint(24) UNSIGNED NOT NULL,
 `produkt_id` int(10) UNSIGNED NOT NULL,
 PRIMARY KEY  (`id`),
 KEY `produkt_id` (`produkt_id`),
 KEY `user_id` (`user_id`),
 KEY `cena` (`cena`)
) ENGINE=MyISAM AUTO_INCREMENT=1357689 DEFAULT CHARSET=utf8
[SQL] pobierz, plaintext 

Wyciąłem kolumny, które nie biorą udziału w zapytaniu. Zresztą jest ich od cholery...
Wiem, wiem - tragedia... ale muszę to jakoś przyspieszyć ;/