Cześć.


Przypuśćmy, że mam 3 tabele:
tab. a (np. 1000 rekordów):
- id (primary key)
- name (varchar unique)

tab. b (np. 1000 rekordów):
-id (primary key)
- surname (varchar unique)

tab. z (>100000 rekordów):
- id (primary key)
- name_id (mediumint)
- surname_id (mediumint)


Teraz chce je połączyć za pomocą join i piszę zapytanie:


SELECT a.id, a.name FROM a JOIN z JOIN b ON
a.name='Piotr' AND b.surname like 'a%' AND a.id=z.name_id AND
b.id=z.surname_id

lub:

SELECT a.id, a.name FROM a JOIN z JOIN b ON a.id=z.name_id AND
b.id=z.surname_id AND a.name='Piotr' and b.surname like 'a%'

lub:

SELECT a.id, a.name FROM z JOIN a JOIN b ON
a.name='Piotr' AND b.surname like 'a%' AND z.name_id=a.id AND
z.surname_id=b.id


Czy kolejność łączenia tabel JOIN bądź kolejność warunków we frazie ON
mają jakieś znaczenie dla wydajnośći? Czy powinienem jakoś jeszcze
zoptymalizować te zapytania, czy MySQL sam to zrobi? A jeśli w tabelach
a i b będzie po ok. 100.000 rekordów a w tabeli z tylko ok. 1000? Czy
jakoś optymalniej należy konstruować SELECTA z JOIN?


Z góry dizęki za objaśnienie.

X t l a n napisał(a):
> Cześć.
>

>
> tab. z (>100000 rekordów):
> - id (primary key)
> - name_id (mediumint)
> - surname_id (mediumint)
>
>
> Czy kolejność łączenia tabel JOIN

nie

bądź kolejność warunków we frazie ON

tak, kolejno od lewej do prawej, Chyba że MySQL to sobie optymalizuje np
na podstaie kluczy.
Pierwszy warunek ma odsiewać jak najwięcej rekordów

> mają jakieś znaczenie dla wydajnośći? Czy powinienem jakoś jeszcze
> zoptymalizować te zapytania, czy MySQL sam to zrobi? A jeśli w tabelach

nie zapytania, tabele

Załóż indeksy na tę tabelę, która zostawilem

> a i b będzie po ok. 100.000 rekordów a w tabeli z tylko ok. 1000? Czy
> jakoś optymalniej należy konstruować SELECTA z JOIN?

Jeżeli użyjesz

SELECT foo FROM tab1, tab2, tab3 WHERE tab1.w=tab2.w AND ...

to BD bedzie mogła sama sobie nieco lepiej zoptamylizować


pBT