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?

[wookieb]

Niestety MyIsam słabo spisuje się w operacjach złączenia (wynika to między innymi z tego powodu, że nie przechowuje głównego indeksu tabeli w kluczach tak jak INNODB).
Po próbie zmiany myisam na innodb złączenia odrazu zaczęły wykorzystywać klucze.
Próbuję "conieco" zoptymalizować tabele i wynikami pochwale się jak tylko uda mi się coś zrobić aczkolwiek zastanów się na przyszłość czy nie lepiej przejśc na INNODB i do wyszukiwania wykorzystać sphinxa bądź inne systemy wyszukiwania (w zastępstwie FULLTEXT).

Ten post edytował wookieb 17.08.2010, 12:40:00