Trong EF Code First, lý do chung tại sao bạn mô hình hóa mối quan hệ khóa ngoài là để điều hướng giữa các thực thể. Hãy xem xét một kịch bản đơn giản của Country và City , với tải nhanh được xác định cho câu lệnh LINQ sau:
var someQuery =
db.Countries
.Include(co => co.City)
.Where(co => co.Name == "Japan")
.Select(...);
Điều này sẽ dẫn đến một truy vấn dọc theo các dòng:
SELECT *
FROM Country co
INNER JOIN City ci
ON ci.CountryId = co.ID
WHERE co.Name = 'Japan';
Không có Chỉ mục trên khóa ngoại trên City.CountryId , SQL sẽ cần quét bảng Các thành phố để lọc các thành phố cho Quốc gia trong một THAM GIA.
Chỉ mục FK cũng sẽ có lợi ích về hiệu suất nếu hàng bị xóa
từ bảng Quốc gia mẹ, vì tính toàn vẹn tham chiếu sẽ cần phát hiện sự hiện diện của bất kỳ hàng Thành phố nào được liên kết (cho dù FK có ON CASCADE DELETE hay không xác định hay không).
TL; DR
Chỉ mục trên Khóa ngoại là được khuyến nghị , ngay cả khi bạn không lọc trực tiếp trên khóa ngoại, nó vẫn cần thiết trong Joins. Các ngoại lệ cho điều này dường như khá giả:
-
Nếu độ chọn lọc của khóa ngoại rất thấp, ví dụ:trong trường hợp trên, nếu 50% TẤT CẢ các thành phố trong bảng quốc gia là ở Nhật Bản, thì Chỉ số sẽ không hữu ích.
-
Nếu bạn thực sự không bao giờ điều hướng trong mối quan hệ.
-
Nếu bạn không bao giờ xóa các hàng khỏi bảng mẹ (hoặc cố gắng cập nhật trên PK).
Một cân nhắc tối ưu hóa bổ sung là có nên sử dụng khóa ngoại trong Clustered Index hay không của bảng con (tức là cụm Thành phố theo Quốc gia). Điều này thường có lợi trong các mối quan hệ cha mẹ:bảng con, nơi nó là nơi phổ biến để truy xuất tất cả các hàng con cho cha mẹ cùng một lúc.
