Jag har två tabeller enligt nedan, Task är själva huvudtabellen och Version som är en tabell som Task.VersionID pekar på. Båda tabellerna har en kolumn som heter ID (int identity) som är PrimaryKey (clustered). Jag har en relation mellan tabellerna (mellan Task.VersionID och Version.ID) och har dessutom satt ett ickeklustrat index på Task.VersionID.

Trots dessa förutsättningar så får jag en Clustered Index Scan (i stället för Clustered Index Seek) när jag ställer frågan :
<info>
select * from Task left join Version on Version.ID = Task.VersionID
</info>
Här är tabellerna :
<info>
Tabell Task :
ID int PK
VersionID int -- Foreign key till Version.ID

Tabell Version
ID int PK
Name varchar
</info>

Någon som kan förklara varför jag inte får en Seek i detta läge?

Skapa (non clustered) index på Task.VersionID int (fk)
Och använd hellre inner join om du kan, det är snabbare.

Jag trodde jag angett all nödvändig info men missade tydligen detta. Jag har (på din inrådan i den andra tråden) satt index på alla foreign keys men får ändå Index Scan...Jag läste dock någonstans att det kan bero på att tabellen är för liten för att det skall vara nödvändigt med Seek? Vad innebär i sådana fall en liten tabell för Query Optimizern?

I mitt testfall har Task ca 6000 poster och Version drygt 20 poster.

Angående left/inner så vill jag i det här fallet ha alla ärenden oavsett om versionID är null så då måste jag väl ha left.

Jag är inte helt hundra på det där med index scan/seek problem,
men det finns väl info om det på webben gissar jag :)

Du kanske bör se till att VersionID aldrig är null? Det känns inte rätt att fk's är null. Om 'ospecificererat' är en nödvändigt tillstånd så är det väl bättre att du t.ex. skapar en VersionID=0, Ospecad. Då kan du ju köra inner join ändå. Troligen kan sql servern optimera bättre på indexerade kolumner som inte tillåter null.

Hmm intressant, jag har massor med sådana fält som kan vara null...listan med optimeringar blir bara längre och längre :-)