Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: nieoptymalne zapytanie?
Forum PHP.pl > Forum > Bazy danych > MySQL
TomASS
Nie będę zbędni się rozpisywał, konkrety: smile.gif

Pada serwer hostingowy (błąd 503) - oczywiście to moja wina, a konkretnie zapytania:
  1. SELECT TR.data_granicy_pl, TR.data_granicy_in,
  2. TR.data_do_klienta, TR.SAD, TR.granica, TR.zaladowane, TR.ID,
  3. TR.dodatkowo, TR.kolor_ntr, TR.data_podstawienia,
  4. TR.numer_wagonu, TR.cUwagiWag, TR.typ , TR.tara, TR.mc,
  5. TR.uwagi_ntr, LA.Data_zal, LA.ID AS IDlad, LA.granica AS granica_EU, LA.customer, LA.koszt_polska, LA.koszt_zagranica,
  6. 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
  7. AS GR ON (LA.granica = GR.ID) WHERE nr_wysylki='2007-23' AND awizacja='ntr' ORDER BY ID

explain zwraca:
Cytat
+----+-------------+-------+--------+---------------+------------+---------+--------------------------------+-------+----------------------------------------------+
| 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
  1. WHERE nr_wysylki='2007-23' AND awizacja='ntr' ORDER BY ID
uzupelnij o brakujace tabele/aliasy.

Indeksy zaloz na warunki i sortowania

Cytat
| 1 | SIMPLE | LA | ALL | NULL | NULL | NULL | NULL | 11788 | |
Sprawdz czy w zapytaniu masz wszystko ok a jak nie to moze jakies podzapytanie.

Cytat
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

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

Pewnie to jest w statusie zapytan

Cytat
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

Cytat
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 winksmiley.jpg. 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.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.