Có một hiệu suất nhỏ ảnh hưởng đến việc chèn, cập nhật và xóa vì FK phải được kiểm tra. Đối với một bản ghi riêng lẻ, điều này thường sẽ rất nhỏ đến mức khó nhận thấy trừ khi bạn bắt đầu có một số lượng FK vô lý được liên kết với bảng (Rõ ràng là mất nhiều thời gian hơn để kiểm tra 100 bảng khác hơn 2). Đây là một điều tốt chứ không phải là một điều xấu vì cơ sở dữ liệu không có tính toàn vẹn sẽ không đáng tin cậy và do đó vô dụng. Bạn không nên đánh đổi tính toàn vẹn để lấy tốc độ. Lần truy cập hiệu suất đó thường được bù đắp bởi khả năng tối ưu hóa kế hoạch thực thi tốt hơn.
Chúng tôi có một cơ sở dữ liệu kích thước trung bình với khoảng 9 triệu bản ghi và FK ở khắp mọi nơi mà chúng nên có và hiếm khi nhận thấy hiệu suất đạt được (ngoại trừ một bảng được thiết kế xấu có hơn 100 khóa ngoại, việc xóa các bản ghi khỏi bảng này sẽ hơi chậm phải được kiểm tra). Hầu hết mọi dba mà tôi biết về những người xử lý cơ sở dữ liệu lớn, có kích thước hàng terabyte và nhu cầu thực sự về hiệu suất cao trên các tập dữ liệu lớn đều nhấn mạnh vào các ràng buộc khóa ngoại vì tính toàn vẹn là chìa khóa cho bất kỳ cơ sở dữ liệu nào. Nếu những người có cơ sở dữ liệu cỡ terabyte có thể chi trả hiệu suất rất nhỏ, thì bạn cũng vậy.
FK không được lập chỉ mục tự động và nếu chúng không được lập chỉ mục, điều này có thể gây ra sự cố về hiệu suất.
Thành thật mà nói, tôi sẽ lấy một bản sao cơ sở dữ liệu của bạn, thêm các FK được lập chỉ mục thích hợp và hiển thị sự khác biệt về thời gian để chèn, xóa, cập nhật và chọn từ các bảng đó so với các bảng tương tự từ cơ sở dữ liệu của bạn mà không có FK. Chứng tỏ rằng bạn sẽ không gây ra một cú đánh hiệu suất. Sau đó, hiển thị kết quả của các truy vấn hiển thị các bản ghi mồ côi không còn ý nghĩa vì PK mà chúng có liên quan đến không còn tồn tại. Đặc biệt hiệu quả khi hiển thị điều này cho các bảng chứa thông tin tài chính ("Chúng tôi có 2700 đơn đặt hàng mà chúng tôi không thể liên kết với khách hàng" sẽ khiến ban quản lý phải ngồi dậy và lưu ý).
