nieoptymalne zapytanie?, niby czemu i jak zoptymalizować? Opcje

[TomASS]

Nie będę zbędni się rozpisywał, konkrety:

Pada serwer hostingowy (błąd 503) - oczywiście to moja wina, a konkretnie zapytania:

[SQL] pobierz, plaintext 
SELECT TR.data_granicy_pl, TR.data_granicy_in, 
TR.data_do_klienta, TR.SAD, TR.granica, TR.zaladowane, TR.ID, 
TR.dodatkowo, TR.kolor_ntr, TR.data_podstawienia, 
TR.numer_wagonu, TR.cUwagiWag, TR.typ , TR.tara, TR.mc, 
TR.uwagi_ntr, LA.Data_zal, LA.ID AS IDlad, LA.granica AS granica_EU, LA.customer, LA.koszt_polska, LA.koszt_zagranica, 
LA.koszt_razem, LA.miejscowosc, LA.masa_razem, MI.Nazwa AS miNazwa, CU.Kraj, CU.Nazwa, GR.Kod FROM pz_transporty AS TR LEFT JOIN pz_ladunki AS LA ON (TR.ID = LA.wagon) LEFT JOIN pz_miejscowosci AS MI ON (LA.miejscowosc = MI.ID) LEFT JOIN pz_customers AS CU ON (LA.customer = CU.ID) LEFT JOIN pz_granica 
AS GR ON (LA.granica = GR.ID) WHERE nr_wysylki='2007-23' AND awizacja='ntr' ORDER BY ID
[SQL] pobierz, plaintext 

explain zwraca:

+----+-------------+-------+--------+---------------+------------+---------+--------------------------------+-------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+------------+---------+--------------------------------+-------+----------------------------------------------+
| 1 | SIMPLE | TR | ref | nr_wysylki | nr_wysylki | 10 | const | 811 | Using where; Using temporary; Using filesort |
| 1 | SIMPLE | LA | ALL | NULL | NULL | NULL | NULL | 11788 | |
| 1 | SIMPLE | MI | eq_ref | ID | ID | 8 | logistyka_knauf.LA.miejscowosc | 1 | |
| 1 | SIMPLE | CU | eq_ref | ID | ID | 4 | logistyka_knauf.LA.customer | 1 | |
| 1 | SIMPLE | GR | eq_ref | ID | ID | 4 | logistyka_knauf.LA.granica | 1 | |
+----+-------------+-------+--------+---------------+------------+---------+--------------------------------+-------+----------------------------------------------+

Indeksy są założone:
A. pz_transporty:
ID
nr_wysylki
numer_wagonu
typ
kod_stacji
customer

B. pz_ladunki
ID
woche
Kolejnosc
nIDPociag
granica

C. pz_customers
ID
Jednostka

D. pz_granica
ID
Kod

1. skąd w explainie wzielo się "Using temporary" - jawnie tablicy tymczasowej nie tworzę
2. skąd mój hostingowiec wie, że tabela tymczasowa zawiera ponad 9 mln rekordów?
3. czy da się jakoś zoptymalizować te zapytanie
4. czy takie zapytanie może być przyczyną upadku serwera (błąd 503)?

Dzięki

[SongoQ]

[SQL] pobierz, plaintext 
WHERE nr_wysylki='2007-23' AND awizacja='ntr' ORDER BY ID
[SQL] pobierz, plaintext 

uzupelnij o brakujace tabele/aliasy.

Indeksy zaloz na warunki i sortowania

| 1 | SIMPLE | LA | ALL | NULL | NULL | NULL | NULL | 11788 | |

Sprawdz czy w zapytaniu masz wszystko ok a jak nie to moze jakies podzapytanie.

1. skąd w explainie wzielo się "Using temporary" - jawnie tablicy tymczasowej nie tworzę

Mozliwe dlatego ze nie masz aliasow czy tabel podanych po where

2. skąd mój hostingowiec wie, że tabela tymczasowa zawiera ponad 9 mln rekordów?

Pewnie to jest w statusie zapytan

3. czy da się jakoś zoptymalizować te zapytanie

Sprawdz czy aby poprawnie jest napisane, nastepnie wywal wszystkie indeksy i zakladaj tylko na warunki a nastepnie sortowanie. Jesli to nie pomoze to kombinuj z podzapytaniem

4. czy takie zapytanie może być przyczyną upadku serwera (błąd 503)?

Mozliwe ze sa limity na CPU lub czas wykonywania.

[tomkiewicz]

zmień strukturę tabeli, aby wystarczyły proste zapytania, bez joinów

[SongoQ]

[qoute]zmień strukturę tabeli, aby wystarczyły proste zapytania, bez joinów[/quote]
Mozesz potwierdzic to przykladami i teoria?

[tomkiewicz]

teoria to właśnie zacytowane przez Ciebie zdanie . Rozłożenie problemu na prostsze zazwyczaj poprawia wydajność, ale czasem trzeba do tego dać troche redundancji (nadmiarowe dane), co wymaga zmiany struktury tabel - po prostu dane obliczenia są wykonywane tylko raz, przy dodawaniu danych.

Przykład? dzwonek.pl

[SongoQ]

@tomkiewicz Rozumumiem o co CI chodzilo, zrozumialem zupelnie cos innego. Takie podejscie jest dobre wtedy gdy tych rekordow jest miliony i operacje zlaczen czy wyliczen generuja spore koszty i czas, mozliwe ze w tym przypadku sie nada.