Các GUID có vấn đề như các khóa cụm vì tính ngẫu nhiên cao. Vấn đề này đã được Paul Randal giải quyết trong chuyên mục Hỏi và Đáp cuối cùng của Tạp chí Technet:Tôi muốn sử dụng GUID làm khóa chỉ mục theo nhóm, nhưng những người khác đang tranh luận rằng nó có thể dẫn đến các vấn đề về hiệu suất với các chỉ mục. Điều này có đúng không và nếu có, bạn có thể giải thích tại sao không?
Bây giờ, hãy nhớ rằng cuộc thảo luận đặc biệt về nhóm các chỉ mục. Bạn nói rằng bạn muốn sử dụng cột làm 'ID', điều đó không rõ ràng là bạn muốn hiểu nó là khóa nhóm hay chỉ là khóa chính. Điển hình là hai phần chồng chéo, vì vậy tôi sẽ giả sử bạn muốn sử dụng nó làm chỉ mục được phân cụm. Lý do tại sao đó là một lựa chọn tồi được giải thích trong liên kết đến bài viết tôi đã đề cập ở trên.
Đối với các chỉ mục không phân cụm, GUID vẫn có một số vấn đề, nhưng gần như không lớn như khi chúng là khóa được phân nhóm ngoài cùng bên trái của bảng. Một lần nữa, tính ngẫu nhiên của GUID tạo ra sự phân tách và phân mảnh trang, có thể chỉ ở cấp chỉ mục không phân cụm (một vấn đề nhỏ hơn nhiều).
Có nhiều truyền thuyết đô thị xung quanh việc sử dụng GUID lên án chúng dựa trên kích thước của chúng (16 byte) so với int (4 byte) và hứa hẹn hiệu suất khủng khiếp sẽ diệt vong nếu chúng được sử dụng. Điều này hơi phóng đại. Một khóa có kích thước 16 có thể vẫn là một khóa rất ổn định, trên một mô hình dữ liệu được thiết kế phù hợp. Mặc dù đúng là lớn gấp 4 lần số int dẫn đến nhiều trang không phải lá có mật độ thấp hơn trong chỉ mục, đây không phải là mối quan tâm thực sự đối với đại đa số các bảng. Cấu trúc b-tree là một cây cân bằng tự nhiên và chiều sâu của việc duyệt qua cây hiếm khi là một vấn đề, vì vậy việc tìm kiếm giá trị dựa trên khóa GUID thay vì khóa INT cũng tương tự về hiệu suất. Việc duyệt qua trang lá (tức là quét bảng) không nhìn vào các trang không phải trang và tác động của kích thước GUID lên kích thước trang thường khá nhỏ, vì bản thân bản ghi lớn hơn đáng kể so với 12 byte bổ sung được giới thiệu bởi GUID. Vì vậy, tôi sẽ thực hiện lời khuyên nghe nói dựa trên 'là 16 byte so với 4' với một hạt muối, khá lớn. Phân tích từng trường hợp cụ thể theo từng trường hợp và quyết định xem tác động kích thước có tạo ra sự khác biệt thực sự hay không:bao nhiêu khác các cột trong bảng (tức là. kích thước GUID có tác động như thế nào đến các trang lá) và có bao nhiêu tham chiếu đang sử dụng nó (tức là. bao nhiêu khác bảng sẽ tăng lên vì thực tế là chúng cần lưu trữ khóa ngoại lớn hơn).
Tôi đang gọi tất cả những chi tiết này như một cách bảo vệ tạm thời đối với các GUID vì chúng đã nhận được rất nhiều báo chí xấu gần đây và một số không được phục vụ. Chúng có giá trị và không thể thiếu trong bất kỳ hệ thống phân tán nào (thời điểm bạn đang nói về chuyển động dữ liệu, có thể là thông qua khuôn khổ sao chép hoặc đồng bộ hóa hoặc bất cứ điều gì). Tôi đã thấy những quyết định tồi tệ được đưa ra dựa trên danh tiếng xấu của GUID khi họ xa lánh mà không có sự cân nhắc thích hợp. Nhưng sự thật là nếu bạn phải sử dụng GUID làm khóa được phân nhóm, hãy đảm bảo rằng bạn giải quyết vấn đề ngẫu nhiên:sử dụng guids tuần tự khi có thể.
Và cuối cùng, để trả lời câu hỏi của bạn: nếu bạn không có cụ thể lý do để sử dụng GUID, sử dụng INT.
