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?

[dr_bonzo]

Hmm, indeksy na kolumnach zlaczen są.

Robisz LEFT JOINA do userów, a potem WHERE user.is_active = 1.
Czyli wlasciwie LEFT JOIN ci nie potrzebny - bo jesli nie znajdize usera to kolumny 'userowe' beda mialy wszedzie NULLe a NULL =?= true zawsze jest NIEspelnione.

Po tej zmianie EXPLAIN dla tabeli userow uzywa u mnie klucza glownego zamiast robic full scan'a.
-----
Przed

Kod

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE u ALL PRIMARY NULL NULL NULL 892 Using where; Using temporary; Using filesort
1 SIMPLE o ref produkt_id,user_id,cena user_id 3 u.user_id 19 Using where
1 SIMPLE a eq_ref PRIMARY,category_id PRIMARY 4 o.produkt_id 1 Using where

// produkty ma alias 'a' (IMG:style_emoticons/default/questionmark.gif) ?

Kod

id    select_type    table    type    possible_keys    key    key_len    ref    rows    Extra    
1    SIMPLE    u    index    PRIMARY    PRIMARY    4    NULL    12    Using index; Using temporary; Using filesort
1    SIMPLE    o    ref    produkt_id,user_id,cena    user_id    3    test.u.user_id    15    Using where
1    SIMPLE    p    eq_ref    PRIMARY,category_id    PRIMARY    4    test.o.produkt_id    1    Using where

jako że danych mam neiwiele (180 ofert) to czasów nie jestem w stanie podać.

Ten post edytował dr_bonzo 17.08.2010, 13:13:15