liviu.costea:

Da, 2005 e versiunea.

Nu am vrut sa complic sql-ul si sa bag indecsi si relatii pentru ca nu influenteaza cu nimic predicatul in discutie, el ramane. Bineinteles ca selectul va fi mai rapid, apar seekuri si nu scanari. Insa tot nu explica de ce apare acest predicat. Nu m-am gandit nici o clipa la marirea excesiva a complexitatii planului de executie, nici nu vad cum s-ar intampla asta. M-am gandit insa ca prefera sa citeasca o zona continua decat I/O la intamplare (foarte costisitor pentru hdd). Insa se ajunge la extreme: prefera sa citeasca zeci de mii de linii decat sa faca doua I/O la intamplare (asta de exemplu daca dau id-urile 1 si 30.000).

Nu neaparat performanta e problema, ci faptul ca IN nu e asa de inofensiv

 

Volumul de date pe care ati realizat acest test este mult prea mic pentru a justifica generalizarea. In momentul acesta tabelele sunt ambele in memorie si el utilizeaza un plan de executie pe care il crede optim pentru aceasta situatie. Pentru tabele care contin volume mari de date, situatie in care apare IO este posibil ca planul de executie sa se schimbe.