Ý nghĩa của việc sử dụng Chỉ mục NonClustered duy nhất với Cột che thay vì Khóa chính

Chúng tôi có một bảng lớn [MyTable]mà hiện nay có cả Primary Key, và một Unique Non Clustered Indextrên cùng một cột ( [KeyColumn]). Chỉ số U NC cũng có các cột che bổ sung.

Có cả PK và Chỉ số NC duy nhất trên cùng một cột có vẻ dư thừa, vì vậy tôi đã xem xét xóa Khóa chính và thay vào đó sử dụng chỉ mục Không phân cụm duy nhất cho mục đích toàn vẹn tham chiếu.

Lưu ý rằng bảng được nhóm hoàn toàn bởi một cột khác.

tức là chúng ta có:

ALTER TABLE [MyTable]
    ADD CONSTRAINT [PK_MyTable] 
    PRIMARY KEY NONCLUSTERED ([KeyColumn])
GO

VÀ

CREATE UNIQUE NONCLUSTERED INDEX [IX_MyTable_SomeIndex] 
    ON [MyTable] ([KeyColumn]) 
    INCLUDE ([Column1], [Column2])
GO

Theo như tôi biết, không thể thêm các cột che vào Khóa chính, vì vậy tôi dự định sẽ làm:

• Bỏ các ràng buộc khóa ngoại dựa vào MyTable.KeyColumn
• Bỏ khóa chính MyTable.KeyColumnhoàn toàn
• Thêm lại các khóa ngoại vào bảng (tức là RI sẽ được thực thi thông qua MyTable.KeyColumn)

Hàm ý duy nhất tôi có thể nghĩ đến khi làm điều này là chúng ta sẽ không nhận được biểu tượng khóa trực quan trên sơ đồ ERD của mình và mật độ chỉ số (lá) sẽ ít hơn do các cột được bao gồm.

Tôi đã đọc /programming/487314/primary-key-or-unique-index và hài lòng với tính toàn vẹn và hiệu suất của việc này.

Câu hỏi của tôi là: Cách tiếp cận này có thiếu sót?

Chỉnh sửa những gì tôi đang cố gắng thực hiện : Tối ưu hóa hiệu suất và làm sạch mùa xuân . Bằng cách xóa PK hoặc Chỉ mục, sẽ có ít trang cần thiết hơn cho chỉ mục của tôi = ghi nhanh hơn, cộng với lợi ích bảo trì / vận hành, tức là chỉ số ít hơn để giữ phân mảnh, v.v.

Để đặt một số nền tảng cho điều này, trước đây tôi chưa bao giờ có một bảng được tham chiếu, không có PK. Tuy nhiên, thực tế là một Chỉ số NC với các cột che được thêm vào bảng có nghĩa là tôi cần điều chỉnh suy nghĩ của mình.

Tối ưu hóa hiệu suất. Bằng cách xóa PK hoặc Chỉ mục, sẽ có ít trang cần thiết hơn cho chỉ mục của tôi = ghi nhanh hơn, cộng với lợi ích bảo trì / vận hành, tức là chỉ số ít hơn để giữ phân mảnh, v.v.

Bạn cần có khả năng chứng minh rằng những gì được đề xuất sẽ thực sự có ích (chi phí so với lợi ích). Vì lý do gì mà sự thay đổi này đang được xem xét? Có thực sự có vấn đề về hiệu suất với bảng này không, hay nó chỉ "nhìn sai"?

Dưới đây là một số câu hỏi khác sẽ giúp bạn đi đến quyết định tốt nhất cho môi trường của bạn:

• Bao nhiêu thời gian sẽ được lưu trong cửa sổ bảo trì? Trong cửa sổ sao lưu?

• Bao nhiêu dung lượng lưu trữ này sẽ tiết kiệm (tệp dữ liệu, tệp nhật ký, sao lưu, v.v.)?

• Là INSERThiệu suất trên bảng này thực sự là một nút cổ chai ngay bây giờ? Nó sẽ cải thiện bao nhiêu? Là loại bỏ một chỉ số là chiến lược tốt nhất để khắc phục vấn đề đó?

• Điều này có gây ra sự cố với các công cụ cơ sở dữ liệu và khung (đặc biệt là ORM) mà mỗi bảng mong muốn có một khóa chính chứ không chỉ là một chỉ mục duy nhất không? Bản sao giao dịch yêu cầu một khóa chính trên các bảng được công bố.

• Là một lược đồ cơ sở dữ liệu tự tài liệu quan trọng?

• Mặc dù hạn chế sử dụng, nhưng sự hẹp hòi của chỉ số khóa chính vẫn cho phép trình tối ưu hóa tạo ra các kế hoạch hiệu quả hơn cho các truy vấn nhất định? (Sử dụng sys.dm_db_index_usage_statsđể tìm hiểu.)

Nói một cách cá nhân, từ những gì bạn đã nói với chúng tôi, tôi sẽ để nó một mình cho đến khi có thể chứng minh rằng cả hai (a) chỉ số phụ là một vấn đề và (b) loại bỏ nó là giải pháp.

Loại truy vấn duy nhất trên bảng đó sẽ hoạt động kém hơn (và chỉ kém hơn một chút) sẽ là những truy vấn yêu cầu một loạt các giá trị KeyColumn - vì các truy vấn đó vào lúc này sẽ được phục vụ tốt nhất bởi một chỉ mục tìm kiếm trên PK của bạn.

Điều đáng ghi nhớ là chi phí kiểm tra tính toàn vẹn tham chiếu cho các bảng tham chiếu bảng này sẽ cao hơn (chỉ cao hơn một chút).

Miễn là bạn quan tâm đến khía cạnh vô giá trị, thì bạn sẽ ổn với chỉ số một.

Nếu đó là DB của tôi, có lẽ tôi sẽ chọn chỉ số duy nhất, tất cả những thứ khác đều bằng nhau.

Theo như tôi biết, không thể thêm các cột che vào Khóa chính

Nếu bạn có một chỉ mục được nhóm trên KeyColumn, thì vì đó là một chỉ mục được nhóm, tất cả các cột khác đều được 'bao phủ'. Vì vậy, bạn không đạt được bất cứ điều gì bằng cách thêm một chỉ mục khác trên KeyColumn. Trong thực tế, bạn sẽ làm chậm phần chèn của mình và sử dụng nhiều dung lượng hơn.

Điều này là do một chỉ mục được nhóm không phải là một chỉ mục như vậy, mà chỉ là một hướng dẫn để lưu trữ các hàng của bảng theo thứ tự của chỉ mục. Và một khi bạn đã mở một hàng bằng khóa chính, thì bạn có tất cả các cột khác ngay tại đó.