![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 124 Pomógł: 1 Dołączył: 13.07.2009 Ostrzeżenie: (0%) ![]() ![]() |
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.
Cytat 20 rows in set (9.70 sec) Bez SQL_CALC_FOUND_ROWS: Cytat 20 rows in set (6.63 sec) To samo zapytanie, ale bez wyciągania danych - zamiast tego COUNT(*): Cytat 20 rows in set (6.71 sec) Teraz wracając do początku: Bez "`u`.`aktywny`=1": Cytat 20 rows in set (1.86 sec) Bez "`u`.`aktywny`=1" oraz bez "ORDER BY `p`.`name` ASC": Cytat 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": Cytat 20 rows in set (1.07 sec) Ostatnie zapytanie, ale bez SQL_CALC_FOUND_ROWS: Cytat 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? |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Przyjaciele php.pl Postów: 5 724 Pomógł: 259 Dołączył: 13.04.2004 Skąd: N/A Ostrzeżenie: (0%) ![]() ![]() |
@mkozak: Ciekawe, twoje zapytanie daje:
Kod id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY p *ALL* PRIMARY,category_id *NULL* NULL NULL 15 Using where; Using filesort 1 PRIMARY o ref produkt_id,cena produkt_id 4 test.p.produkt_id 12 Using where 2 DEPENDENT SUBQUERY u ref shop_active shop_active 5 const,test.o.user_id 2 Using where; Using index Ten post edytował dr_bonzo 17.08.2010, 16:02:23 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 26.09.2025 - 09:01 |