![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 11 Pomógł: 0 Dołączył: 29.09.2008 Ostrzeżenie: (0%) ![]() ![]() |
Witam,
mam dosc spora baze (ok. 3 mln rekordow) z firmami w ktorej pojawil mi sie problem przy zapytaniu ktore pobiera dane firmy wg. okreslonej branzy, a wyniki sortuje po polu liczbowym - 'priorytet'. Tabele mam w innoDB a czas query siega 20sekund: Oto zapytanie:
Budowa tabeli firmy:
Budowa tabeli zlaczeniowej branz:
Wynik explain zapytania pokazuje taki rezultat (niepokojacy dla tabeli firma_branza):
Czy ktos pomoze w probie ustawienia odpowiednich indeksow zeby to dzialanie zoptymalizowac ? |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 341 Pomógł: 40 Dołączył: 23.06.2009 Ostrzeżenie: (0%) ![]() ![]() |
czas masz z uwagi na to ze zapytanie wymaga tabeli tymczasowej (wymuszone najpewniej przez order by)
z czystej ciekawosci sprawdź (nie testowalem zapisu) :
sprawdz czasy, wydaje mi sie ze nawet jesli dodasz order by - takie zlaczenie powino zadzialac ciut lepiej. j. |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 11 Pomógł: 0 Dołączył: 29.09.2008 Ostrzeżenie: (0%) ![]() ![]() |
czas masz z uwagi na to ze zapytanie wymaga tabeli tymczasowej (wymuszone najpewniej przez order by) z czystej ciekawosci sprawdź (nie testowalem zapisu) :
sprawdz czasy, wydaje mi sie ze nawet jesli dodasz order by - takie zlaczenie powino zadzialac ciut lepiej. j. Minimalnie, ale ewidentie chodzi o ten order by... to zabija moje zapytanie. Witam.
Spokojnie typ pola priorytet można zmienić na ENUM. Co do samego zapytania.
Typy pol mialem calkiem dobrze ponazywane. Pozmienialem tylko dla status, priorytet z TINYINT 1 na ENUM. Poprawa jest ale niewielka. Dziwne ze ANALYSE z pola Varchar 255 proponuje jako bardziej optymalne TINYTEXT. Czyzby wyszukiwanie w TINYTEXT bylo szybsze niz w Vatcharach ? Co do twojej propozycji zmiany zapytania USE INDEX(id_branza) wywala blad bo indeks id_branza jest na tabeli "firma_branza" a nie na "firma" Nie potrafię, odpowiedzieć jakby to można było przyspieszyć ale mam pytanie: celowo robiłeś trzy branże dla każdej firmy? A jak firma należy do czeterech branż? Dla jednej branży masz przyporządkowaną jedną a w dwóch pozostałych NULL? Ja bym to rozbił na 3 tabele choć na 100% byłoby jeszcze wolniej, choć ładniej (IMG:style_emoticons/default/smile.gif) Troche zle to interpretujesz. Tabela "firma_branza" jest tabela laczaca tabele "firma" i "branza" (ktorej nie podawalem bo zapytanie jej nie dotyczy). id_branza_1, id_branza_2, id_branza_3 oznacza strukture drzewa branz, natomiast kazdy nowy rekord w "firma_branza" oznacza zaklasyfikowanie firmy do kolejnej branzy - takich klasyfikacji moze byc wiele. @gpi: jesli chodzi o indeksy, lepiej ci zadzialaja 3 osobne indeksy na branze, niz jeden dla wszystkich (chyba ze zawsze korzystasz z pola id_branza_1) tzn chodzi mi o to, ze jeseli bedziesz szukal tylko po polu id_branza_3 - to ten index nie zostanie wykorzystany. Wlasnie zawsze podaje caly ciag branz, moge miec: WHERE id_branza_1='1' lub WHERE id_branza_1='1' AND id_branza_2='56' lub WHERE id_branza_1='1' AND id_branza_2='56' AND id_branza_3='16' nigdy samo id_branza_2, id_branza_3 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 14.10.2025 - 23:37 |