Deluje cudno. Ja bih rekao da je razlika u tome sto je SELECT DISTINCT skuplja operacija od SELECT, ali s obzirom da imas 206 zapisa onda to otpada, razlike bi bile zanemarljive u malom broj slucajeva, jedino ako ti ID nije nvarchar(max), ili tako nesto egzoticno

ID je int
Jedna tabela ima 20k zapisa, treca ima oko 80k zapisa, a ova izmedju svega desetak
ne znam da li igra ulogu kako sam joinovao tabele, jer on prolazi - vraca mi rezultate besprekorno brzo i tacno, samo ako ne stavim distinct.
Join je 1 na 1, jednom redu prve odgovara jedan red trece tabele, druga (najmanja) sluzi samo za vezivanje prve i trece.

Nisam siguran, ali deluje logicno da posle svih joinova se radi distinct. Probaj da vratis sa podupitom rezultat, mozda se query optimizer zakuca, mada to je isto malo verovatno



E da, javi samo rezultat, bas me zanima sta je uzrok ovome.

Ako vracas samo jednu (ili mali broj) kolonu pokusaj sa gruop by umesto distinct (doduse trebalo bi da generisu isti plan ali probaj). Takodje mozda mozes da rewrite-ujes upit sa where exists (primer: http://www.sql-server-performa...elect_distinct_queries_p1.aspx ).

Cek samo malo, ako sam shvatio ti imas 1-1 relaciju preko link tabele? Ako smem da pitam sto si to tako radio, zasto ne direktna relacija?

Isto malo mi je cudno da u toj 1-1 konfiguraciji distinct vraca manje rezultata, da bi se neki ID duplirao i time bio podlozan distinct-u kroz join mora da postoji many-to-0/1 u kom slucaju ti je onda poslovna logika zakazala i dozvolila unos podatka koji nije 1-1 .

U svakom slucaju baci nam ovde ako mozes estimated plan za distinct i actual plan za bez distinct-a, distinct bi trebao da je finalni filter na planu, ne bi trebao da utice na ostatak plana.

Isto sto mozes da uradis je da dok cekas tih 10 minuta pogledas ko ti drzi lockove na objekte, tvoj query moze da ima samo IS i S lockove i bar jedan je u WAIT stanju, pogledaj koji drugi proces drzi granted lock na istom resursu i vidi oklen on