Entity Framework Indexerar ALLA kolumner för främmande nyckel

I EF Code First är det allmänna skälet till att du skulle modellera en främmande nyckelrelation för navigering mellan enheter. Tänk på ett enkelt scenario med Country och City , med ivrig laddning definierad för följande LINQ-sats:

var someQuery = 
   db.Countries
     .Include(co => co.City)
     .Where(co => co.Name == "Japan")
     .Select(...);

Detta skulle resultera i en fråga i stil med:

SELECT *
FROM Country co
INNER JOIN City ci
  ON ci.CountryId = co.ID
WHERE co.Name = 'Japan';

Utan ett index på den främmande nyckeln på City.CountryId , SQL kommer att behöva skanna tabellen Städer för att filtrera städerna för landet under en JOIN.

FK-indexet kommer också att ha prestandafördelar om rader raderas från tabellen överordnat land, eftersom referensintegritet kommer att behöva upptäcka närvaron av alla länkade stadsrader (om FK har ON CASCADE DELETE definierad eller inte).

TL;DR

Indexer på främmande nycklar är rekommenderas , även om du inte filtrerar direkt på den främmande nyckeln, kommer den fortfarande att behövas i Joins. Undantagen från detta verkar vara ganska konstruerade:

• Om selektiviteten för den främmande nyckeln är mycket låg, t.ex. i scenariot ovan, om 50 % av ALLA städer i tabellen över länder var i Japan, skulle indexet inte vara användbart.

• Om du faktiskt aldrig navigerar över förhållandet.

• Om du aldrig tar bort rader från den överordnade tabellen (eller försöker uppdatera på PK) .

En ytterligare optimeringsövervägande är om den främmande nyckeln ska användas i Clustered Index i den underordnade tabellen (dvs. kluster Städer efter land). Detta är ofta fördelaktigt i överordnade :underordnade tabellrelationer där det är vanligt att hämta alla underordnade rader för föräldern samtidigt.