V EF Code First je obecným důvodem, proč byste modelovali vztah cizího klíče, navigace mezi entitami. Zvažte jednoduchý scénář Country
a City
, s dychtivým načítáním definovaným pro následující příkaz LINQ:
var someQuery =
db.Countries
.Include(co => co.City)
.Where(co => co.Name == "Japan")
.Select(...);
Výsledkem by byl dotaz ve smyslu:
SELECT *
FROM Country co
INNER JOIN City ci
ON ci.CountryId = co.ID
WHERE co.Name = 'Japan';
Bez indexu cizího klíče na City.CountryId
, SQL bude muset naskenovat tabulku Cities, aby mohla během JOIN filtrovat města pro zemi.
Index FK bude mít také výkonnostní výhody, pokud budou řádky odstraněny
z nadřazené tabulky Země, protože referenční integrita bude muset detekovat přítomnost jakýchkoli propojených řádků města (zda má FK ON CASCADE DELETE
definované nebo ne).
TL;DR
Indexy cizích klíčů jsou doporučeno , i když nefiltrujete přímo cizí klíč, bude stále potřeba v Joins. Výjimky se zdají být docela vymyšlené:
-
Pokud je selektivita cizího klíče velmi nízká, např. ve výše uvedeném scénáři, pokud by 50 % VŠECH měst v tabulce zemí bylo v Japonsku, pak by index nebyl užitečný.
-
Pokud ve vztahu nikdy neprojdete.
-
Pokud nikdy neodstraníte řádky z nadřazené tabulky (nebo se pokusíte aktualizovat na PK).
Dalším aspektem optimalizace je, zda použít cizí klíč v Clustered Index
podřízené tabulky (tj. seskupení měst podle země). To je často výhodné ve vztazích nadřazených:podřízených tabulek, kde je běžné načíst všechny podřízené řádky pro nadřazenou položku současně.