IN turi limita kiek elementu eina idet, tai po to jei ju bus su laiku daug tai teks arba skaldyt i kruva uzklausu arba naudot pvz temporary table, kur visus elementus i ja sukraut ir traukt su INNER JOIN per ja.. bent tada neatrodys kaip kazkoks jovalas tavo kurinys :)

"@work" <work@work.lt> wrote in message news:hdr9bq$drn$1@trimpas.omnitel.net...
> 
> kaip veikia IN'as nebepasakysiu, bet OR atveju tikrinama iki pirmos 
> teisingos salygos. t.y. isrikiuoji salygas taip, kad pradzioje butu pati 
> dazniausia reiksme ir taip rikiuoji daznumo mazejimo tvarka. Tada greicio 
> atzvilgiu pats geriausias sprendimas.
> 
> 
> "ledasl" <root@localhost.local> wrote in message 
> news:hdr1gi$vl7$1@trimpas.omnitel.net...
>> execution planas toks pats, bet tik tiek. Pabandzius praktiskai pasimato, 
>> kad OR grandine uzklausa pas mane atliekama 6 kartus greiciau, nei IN.
>>
>> "Laimis" <wiela@centras.lt> wrote in message 
>> news:hdk31d$6gm$1@trimpas.omnitel.net...
>>> VyvIT rašė:
>>>> SET STATISTICS TIME ON
>>>> SET STATISTICS IO ON
>>>>
>>>> --tavo uzklausa--
>>>>
>>>> SET STATISTICS TIME OFF
>>>> SET STATISTICS IO OFF
>>>>
>>>> --Messages tabe rasi rezultata--
>>>
>>> Taip, tik pirma vertėtų palyginti execution planus...
>>>
>>> Ir paaiškės, kad nėra jokio skirtumo (ir profiliuoti neverta); 
>>> optimizer'is IN traktuoja (pasiverčia į) OR grandinę.
>>> Skirtumas nebent tik tas, kad IN() sintaksė yra trumpesnė ir aiškesnė.
>>>
>> 
>