GUID 128 bit (uniqueidentifier khóa) tất nhiên lớn hơn gấp 4 lần so với int 32 bit Chìa khóa. Tuy nhiên, có một số ưu điểm chính:
- Không có vấn đề "CHÈN IDENTITY" khi hợp nhất nội dung
- Nếu bạn sử dụng giá trị COMB thay vì NEWSEQUENTIALID (), bạn sẽ nhận được dấu thời gian CHÈN "miễn phí". Bạn thậm chí có thể
SELECTtừ khóa chính dựa trên phạm vi ngày / giờ nếu bạn muốn với một vàiCAST()ưa thích cuộc gọi. - Chúng là duy nhất trên toàn cầu, điều này trở nên khá hữu ích ngay bây giờ và sau đó.
- Vì không cần theo dõi các vết nước cao, lớp BL của bạn có thể chỉ định giá trị thay vì SQL Server, do đó loại bỏ bước
SELECT scope_identity()để lấy khóa chính sau khi chèn. - Nếu có thể từ xa bạn có thể có hơn 2 tỷ bản ghi, bạn sẽ cần sử dụng
bigint(64 bit) thay vìint. Sau khi bạn làm điều đó,uniqueidentifierchỉ lớn gấp đôi mộtbigint. - Việc sử dụng GUID giúp an toàn hơn khi để lộ các khóa trong URL, v.v. mà không khiến bạn bị các cuộc tấn công "đoán là ID".
- Giữa cách SQL Server tải trang từ đĩa và cách bộ xử lý hiện chủ yếu là 64 bit, chỉ vì một số là 128 bit thay vì 32 không có nghĩa là phải mất gấp 4 lần để so sánh. Thử nghiệm cuối cùng mà tôi thấy cho thấy GUID nhanh như nhau.
- Kích thước chỉ mục phụ thuộc vào bao nhiêu các cột được bao gồm. Mặc dù bản thân các GUID lớn hơn, nhưng 8 hoặc 12 byte thừa có thể không đáng kể so với các cột khác trong chỉ mục.
Cuối cùng, việc loại bỏ một số lợi thế hiệu suất nhỏ bằng cách sử dụng số nguyên có thể không đáng làm mất đi những lợi thế của GUID. Hãy kiểm tra nó theo kinh nghiệm và tự quyết định.
Cá nhân tôi vẫn sử dụng cả hai, tùy thuộc vào tình huống, nhưng yếu tố quyết định chưa bao giờ thực sự ảnh hưởng đến hiệu suất trong trường hợp của tôi.
