[SQL]Jak najmniej zapytan sql, Laczenie 2 tabel w 1 zapytaniu sql Opcje

[marcio]

Witam mam takie male pytanie jako ze w sql nie jestem zabardzo wtajemniczony chcialem zapytac o jedna rzecz np w moim cms robie 7 zapytan sql na stronie glownej i chcialem zapytac czy nie obciazy to bazy przy duzej ilosci user'ow nie mowie tu o 100 user'ach ale cos kolo 2-3k to jest pytanie dotyczace teorii duzo ludzi mi pisze o jak szybko chodzi twoj cms i moje pytanie jest takie czy bedzie duza roznica przy szybkosci cms gdy mam teraz 100 user'ow a gdy ich bedzie 2-3k??

Chodzi o to ze jesli roznica moze byc dosyc duza to moze przemysle to i jak bede przepisywal cms na funkcje to zoptymalizuje tez kod sql w sumie jak narazie to robie tak tam gdzie mam pobierac tylko jeden rekord daje limit 1 jednak wczesniej tego nie robilem tam gdzie mam np 15 kolumn w tabeli a musze wyciagnac tylko mala czesc z nim to zamiast dawac * podaje tylko nazy kolumn ale czy to wystarcza??

[sniezny_wilk]

Witam mam takie male pytanie jako ze w sql nie jestem zabardzo wtajemniczony chcialem zapytac o jedna rzecz np w moim cms robie 7 zapytan sql na stronie glownej i chcialem zapytac czy nie obciazy to bazy przy duzej ilosci user'ow nie mowie tu o 100 user'ach ale cos kolo 2-3k to jest pytanie dotyczace teorii duzo ludzi mi pisze o jak szybko chodzi twoj cms i moje pytanie jest takie czy bedzie duza roznica przy szybkosci cms gdy mam teraz 100 user'ow a gdy ich bedzie 2-3k??

Chodzi o to ze jesli roznica moze byc dosyc duza to moze przemysle to i jak bede przepisywal cms na funkcje to zoptymalizuje tez kod sql w sumie jak narazie to robie tak tam gdzie mam pobierac tylko jeden rekord daje limit 1 jednak wczesniej tego nie robilem tam gdzie mam np 15 kolumn w tabeli a musze wyciagnac tylko mala czesc z nim to zamiast dawac * podaje tylko nazy kolumn ale czy to wystarcza??

2-3k * 7 zapytań to jest nic dla bazy Inną sprawą jest transfer, przepustowość łączy, serwer itp..

[mike]

Nie ilość zapytań ma znaczenie tylko ich jakość. 7 zapytań to pikuś. Nawet jakbyś miał ich 20 czy 30 to nie byłoby to jeszcze takie dziwne.
Najważniejsze jest to by były zoptymalizowane i wyciągały to co potrzebujesz w sposób najlepszy i najbardziej oszczędny jak się da.

[marcio]

Inną sprawą jest transfer, przepustowość łączy, serwer itp..

Mozesz rozwinac idee moj cms stoi na bezplatnym servie wiec bedzie krucho ale napewno zmienie o to sie nie marwtie bardziej zalezy mi na kodzie

A jeszcze jedno czy duzo daje cachowanie i co najlepiej cachowac??

@mike no dzieki to przeanalizuje kod napisze go na funckje i zooptymalizuje jak moge zapytania sql

Ten post edytował marcio 13.06.2008, 15:55:33

[erix]

Mozesz rozwinac idee moj cms stoi na bezplatnym servie wiec bedzie krucho

Jak masz źle napisane zapytania, to i na współdzielonym, płatnym się wyłoży.

Najprościej zacząć od dodania indeksów do bazy. ;]
"Głębiej", to już jest studium przypadku...

A jeszcze jedno czy duzo daje cachowanie i co najlepiej cachowac??

Hmm, co wg Ciebie jest szybsze: gdy masz przygotowane (przefiltrowane, posortowane) wyniki do zapytania, czy gdybyś miał za każdym razem je z bazy wyciągać? Chyba oczywiste, że to pierwsze... Fakt, niektóre silniki db mają wbudowane mechanizmy cache'owania najczęściej wykonywanych zapytań (o ile dobrze pamiętam, InnoDB w MySQL), ale jakkolwiek - odczyt z pliku albo serwera/mechanizmu przeznaczonego specjalnie do przechowywania cache'u (memcached, shmop, apc) będzie szybszy niż wykonanie zapytania.

A co cache'ować? Tyle, ile się da. Oczywiście, czas ważności cache'u musisz ustalić wg potrzeb, aby strona w dalszym ciągu była funkcjonalna.

Przy ilości odwiedzin liczonej w tysiącach, cache ważny choć na 1 minutę już trochę da. Idealnie byłoby, gdybyś zaimplementował taki mechanizm cache'owania, który odświeżałby dane w zależności od potrzeb (np. czasem newsy na stronie są aktualizowane kilkukrotnie w ciągu godziny, czasem raz na parę godzin. Wtedy usuwanie cache byś nie uzależnił od czasu, a od aktualizacji zawartości).

Przynajmniej, takie jest moje zdanie. ;]

[Riklaunim]

na niedużym ruchu problemów z wydajnością bazy być nie powinno. Przy większej skali:
- Memcached do keszowania zapytań
- Sphinx do wszystkich pełnotekstowych zapytań (wyszukiwarki itp.)
- unikać złożonych zapytań

A na jeszcze większej:
- replikacja bazy danych

[marcio]

Hehe nawet nie wiem jak cachowac zapytanie ani wyniki nie bawilem sie tym nigdy nie czytalem o tym nigdy dlatego pytam a tak w ogole to nie korzystam z gotowych klas dla mysql sam wszystko pisze bo nie wiem co to te InnoDb jesli o to chodzilo