![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 82 Pomógł: 1 Dołączył: 18.09.2011 Ostrzeżenie: (0%) ![]() ![]() |
Czesc,
mam zapytanie, ktore jeszcze nie zawiera 100% okreslonych pozycji, a juz generuje sie ponad 4s. Baza jest w miare przyzwoicie zindeksowana. Chcialbym zasiegnac Waszej opinii, czy jest mozliwosc ulepszenia samego zapytania. Zapytanie:
probowalem pozbyc sie podzapytan i stworzylem cos takiego
dziala o wiele szybciej ale pojawia sie kwestia filtrowania wg countow , gdyz wrzucajac do warunku where przykladowo count( tuser_log.id )=1 wyrzuca "invalid use of group function". Moze to jakas moja niewiedza... dlatego chcialbym zasiegnac Waszej opinii. A gory dzieki za pomoc. edit. zapomnialem dodac, ze ify sa wstawione po to, zeby uniknac wartosci NULL w zapytaniu (kwestia uzycia kwerendy w frameworku.. nie ma filtrow obslugujacych nulle) Wasp update. zapomnialem o having ![]() ![]() Ten post edytował Wasper 22.05.2012, 09:19:57 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 341 Pomógł: 40 Dołączył: 23.06.2009 Ostrzeżenie: (0%) ![]() ![]() |
zalezy od tego czy te indeksy wykorzystujesz, oraz jakiego rodzaju jest to zapytanie.
pamietaj, ze baza danych, na innodb domyslnie sortuje wiersze wg glownego indeksu. jesli wybierasz wg innego warunku (niz id autoinc.), a do tego musisz sortowac wynik, sprawa jest wtedy otwarta - ustaw glowny index na kolumne, po ktorej musisz sortowac/wybierac. przyklad: klasyczny przyklad tabelki z drzewkiem
zmiana kluczy
i teraz samo zapytanie:
tabela wypelniona okolo 10000 rekordow, jak widac - drzewko kodow. roznica miedzy jedna tabela a druga to : ~~4 sec vs ~~0.8 po zastanowieniu, i tak przerobilem to jeszcze zupelnie inaczej - ale to juz inna bajka ![]() chodzi mi o to ze w powyzszym przykladzie, (przerabialem juz istniejaca tabele) kolumna test_id jest nie tylko zbędna, ale i szkodliwa. unikalnosc mam zapewniona na poziomie pola code, i to jest takze prawdziwy klucz glowny. (mozna dodac uniqa na tym polu). w tym konkretnym przypadku klucz primary na kolumnie test_id - szkodzi. edit.: w wersji bez indexu primary - zapytanie powinno wskazywac na polaczenie po kolumnie code czyli :
zapytanie wtedy jeszcze znaczniej przyspieszy. [w testach, ale juz na mocniejszej maszynie - do ~~0.1 s] j. Ten post edytował alegorn 22.05.2012, 14:15:01 |
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 14.08.2025 - 20:57 |