![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 38 Pomógł: 0 Dołączył: 29.06.2009 Ostrzeżenie: (0%) ![]() ![]() |
Mam pytanie jak używam w jednym zapytaniu kilkanaście razy 'inner join' to jakoś obciążam dodatkowo bazę? Czy zapytania takiego typu(patrz dół) są dobre?
|
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 748 Pomógł: 388 Dołączył: 21.08.2009 Skąd: Gdynia Ostrzeżenie: (0%) ![]() ![]() |
w większości sytuacji JOIN będzie wydajniejszy niż oddzielne zapytania i na pewno w taki sposób powinieneś uczyć się wyciągać relacyjne dane, a w odpowiedzi na Twoje pytanie: tak jest to dodatkowe obciążenie, ponieważ wyciągasz zestawy danych powiązanych ze sobą z różnych tabeli
|
|
|
![]()
Post
#3
|
|
Grupa: Moderatorzy Postów: 8 989 Pomógł: 1550 Dołączył: 8.08.2008 Skąd: Słupsk/Gdańsk ![]() |
Załóż odpowiednie indeksy na tabelach to obciążenie spadnie.
|
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 1 729 Pomógł: 346 Dołączył: 4.04.2009 Ostrzeżenie: (0%) ![]() ![]() |
Mam takie pytanie, a co dadzą indeksy jak joinowanie tabel tworzy w pamięci wirtualną kopie tych 2 i więcej połączonych tabel bez indeksów i na niej działa? Przy dużych tabelach pojawiają się straszne opóźnienia.
Czy mógłby mi to ktoś wyjaśnić? Jest duża szansa, że się mylę, ale w firmie powstał praktycznie zakaz używania joinów i innodb (IMG:style_emoticons/default/smile.gif) |
|
|
![]()
Post
#5
|
|
Grupa: Moderatorzy Postów: 8 989 Pomógł: 1550 Dołączył: 8.08.2008 Skąd: Słupsk/Gdańsk ![]() |
Czy mógłby mi to ktoś wyjaśnić? Jest duża szansa, że się mylę, ale w firmie powstał praktycznie zakaz używania joinów i innodb (IMG:style_emoticons/default/smile.gif) Masakra. Po pierwsze połączenie tabel odbędzie się tylko na rekordach, które spełnia odpowiednie warunki. Więc nie zawsze oznacza to że całą połączona struktura danych jest tam gdzieś przechowywana nawet jeżeli nie są potrzebne. InnoDb + indeksy jest lepszą kombinacja niż MyIsam + indeksy z tego względu,że innodb przechowuje główny identyfikator tabeli w każdym indeksie (co prawda czyni je to większymi ale wzrost wydajności jest dość znaczny). Mysql, pomimo tego jak bardzo się na niego psioczy, bardzo dobrze radzi sobie z indeksami (oraz ich sprytnym wykorzystaniem) tak też im szybciej programiści je poznają tym lepiej dla wszystkich. Przypadek o którym mówisz może wystąpić przy dziwnych podzapytaniach, unionach oraz źle skonstruowanych zapytań nie używających indeksów. P.s. Od MyISAM się odchodzi. Ten post edytował wookieb 31.12.2010, 12:09:34 |
|
|
![]()
Post
#6
|
|
Grupa: Zarejestrowani Postów: 1 729 Pomógł: 346 Dołączył: 4.04.2009 Ostrzeżenie: (0%) ![]() ![]() |
To teraz mnie zaciekawiłeś, czy mógłbyś mi podać jakąś lekturę (bądź artykuł)? Podobno innodb sprawia bardzo duże problemy z fragmentacją danych.
Sam z chęcią używałem innodb, joinów itd. ale były to nieduże strony więc problemów z wydajnością nie ma, ale na jednym z serwisów z firmy mamy bazę 100gb i na inno z joinami niestety dość wolno to działa (oczywiście indeksy są) |
|
|
![]()
Post
#7
|
|
Grupa: Moderatorzy Postów: 8 989 Pomógł: 1550 Dołączył: 8.08.2008 Skąd: Słupsk/Gdańsk ![]() |
Tworzenie indeksów to bardzo wymyślny proces. Zależy do zapytań select, ilości danych przechowywanych oraz selektywności indeksów. Generalnie trochę roboty.
Co do tak dużej tabeli można pomyśleć o zastosowaniu tabel Merge. W ostateczności (jeżeli merge i indeksowanie nie zda egzaminu) należy zastosować inne bazy danych. W przypadku o którym mówisz warto pomyśleć o HBASE, Cassandra. Godna zainteresowanie jest również platforma hadoop. Info o innodb można uzyskać z manuala. Co do fragmentacji nie pamiętam, ale jutro poszukam info ale na pierwszy rzuk oka raczej lepiej sobie radzi. Ten post edytował wookieb 31.12.2010, 23:49:07 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 26.08.2025 - 16:34 |