[rss]

Pytanie: czy wykonując zapytanie

SELECT a.x, b.y

FROM a

JOIN b ON a.klucz=b.klucz

WHERE a.warunek=1

najpierw jest robiony

JOIN

, a dopiero potem filtrowanie względem pola

a.warunek

czy może na odwrót - najpierw filtrowana jest tabela

a

, a dopiero na podstawie otrzymanych wyników wykonywany jest

JOIN

? Co w przypadku, gdybym zmienił filtr na

b.warunek=1

?

#kiciochpyta #komputery #bazydanych #mysql #innodb

[atomowy_zenon]

@rss: nie nie! Przy JOINie musi byc DROP TABLE!

[T.....K]

@rss: a czy to nie jest zadanie dla optymalizatora zapytań a nie dla ciebie?

[rss]

@TzK: nie wiem co konkretnie wykonuje mi wtedy optymalizator, więc wolę zapytać.

[l.....h]

@rss: jak dla mnie to najpierw warunek - ale to tylko moje przypuszczenia:)

[T.....K]

@lo0kash: a nie da się zamienić kolejność że WHERE dajesz przed JOIN?

[T.....K]

@lo0kash: http://easysql.wordpress.com/2011/02/11/kolejnosc-wykonywania-elementow-zapytania-czyli-uwaga-na-union/

tutaj piszą że zawsze JOIN przed WHERE

i że teoretycznie bo ulegają optymalizacji

[rss]

@lo0kash: no właśnie to wcale nie jest takie pewne (szczególnie w sytuacji, gdy pojawi się wiele warunków dla różnych tabel).

@TzK: chyba nie, ale można zrobić zapytanie w zapytaniu, np.

SELECT * FROM a WHERE warunek=1

[l.....h]

@TzK: ciekawe... widocznie tak musi byc :)

[l.....h]

@rss: tak ale w twoim przypadku warunek byl na "glownej" tabeli dlatego pomyslalem ze najpioerw to potem join. Ale pewnie to juz optymalizotor robi.

[jubal]

@rss: zależne od optymalizatora i indeksów, zrób EXPLAIN lub odpowiednik i zobacz, co powie.

[plushy]

@TzK: To jest kolejność logiczna, ważna jest tylko przy parsowaniu zapytania. To jak się naprawdę to wykonuje to już inna para kaloszy.

[T.....K]

@plushy: no... tak

[rss]

@jubal: wow, nie znałem tego, dzięki!

[m.....q]

@rss: @jubal

EXPLAIN EXTENDED pokaze Ci dokladnie jak wyglada zapytanie po przejsciu przez optymalizatora.Tak wiec to co sobie napiszesz to jedno, a to co zrobi z tego optymalizator to

[rss]

@msq: hmm... ciekawe, nie ma najmniejszej różnicy pomiędzy wynikami EXPLAIN i EXPLAIN EXTENDED. :|

[m.....q]

@rss: RTFM. :) Przy EXPLAIN EXTENDED musisz jeszcze wypuscic SHOW WARNINGS\G zeby zobaczyc dodatkowe informacje.

[rss]

@msq: ...racja, wybacz. :(

[gw019]

@rss: mySQL do wersji 5.6 przetwarza zapytania zawsze zgodnie z algorytmem zagnieżdżonych pętli (Nested Loops). Inne bazy, np. Oracle mogą wybrać ścieżkę Sort-Merge, czyli najpierw sort filtrujący na tabelach łączonych, następnie łączenie po wyliczonym hashu. Ta druga jest zwykle bardziej efektywna dla przetwarzania dużych ilości danych jeśli jesteś zainteresowany wykonaniem całości w jak najkrótszym czasie.

Tu masz opis jak działa nested loops krok po kroku http://dev.mysql.com/doc/refman/5.6/en/nested-loop-joins.html, możesz się dowiedzieć jak