Trong công việc của tôi, chúng tôi sử dụng UUID làm PK. Điều tôi có thể nói với bạn từ kinh nghiệm là KHÔNG SỬ DỤNG CHÚNG làm PK (nhân tiện, SQL Server).
Đó là một trong những điều mà khi bạn có ít hơn 1000 bản ghi thì không sao, nhưng khi bạn có hàng triệu, đó là điều tồi tệ nhất bạn có thể làm. Tại sao? Bởi vì UUID không tuần tự, vì vậy mỗi khi một bản ghi mới được chèn vào, MSSQL cần phải xem trang chính xác để chèn bản ghi vào, sau đó chèn bản ghi. Hậu quả thực sự tồi tệ của việc này là các trang có tất cả các kích thước khác nhau và cuối cùng chúng bị phân mảnh, vì vậy bây giờ chúng ta phải khử phân mảnh định kỳ.
Khi bạn sử dụng autoincrement, MSSQL sẽ luôn đi đến trang cuối cùng và bạn kết thúc với các trang có kích thước bằng nhau (trên lý thuyết) vì vậy hiệu suất để chọn các bản ghi đó tốt hơn nhiều (cũng vì INSERT sẽ không chặn bảng / trang đối với rất lâu).
Tuy nhiên, lợi thế lớn của việc sử dụng UUID làm PK là nếu chúng ta có các cụm DB, sẽ không xảy ra xung đột khi hợp nhất.
Tôi muốn giới thiệu mô hình sau:1. PK INT Identity2. Cột bổ sung được tạo tự động dưới dạng UUID.
Bằng cách này, quá trình hợp nhất có thể thực hiện được (UUID sẽ là khóa THỰC SỰ của bạn, trong khi PK chỉ là thứ tạm thời mang lại cho bạn hiệu suất tốt).
LƯU Ý:Đó là giải pháp tốt nhất là sử dụng NEWSEQUENTIALID (như tôi đã nói trong phần bình luận), nhưng đối với ứng dụng cũ không có nhiều thời gian để cấu trúc lại (và thậm chí tệ hơn là không kiểm soát tất cả các lần chèn) thì không thể thực hiện được. kể từ năm 2017, tôi muốn nói rằng giải pháp tốt nhất ở đây là NEWSEQUENTIALID hoặc thực hiện Guid.Comb với NHibernate.
Hy vọng điều này sẽ giúp
