Sử dụng GUID trong các khóa chính/chỉ mục bị đánh cắp

Question

Tôi khá thành thạo trong SQL server performace nhưng tôi gần như phải tranh luận ý tưởng rằng GUIDs nên được sử dụng làm loại mặc định cho Clusterd Primary Keys.

Giả sử rằng bảng có số lượng chèn khá thấp mỗi ngày (5000 +/- hàng/ngày), chúng tôi có thể chạy loại vấn đề gì? Phân chia trang sẽ ảnh hưởng như thế nào đến hiệu suất tìm kiếm của chúng tôi? Bao lâu tôi nên reindex (hoặc tôi nên chống phân mảnh)? Tôi nên đặt các yếu tố điền vào (100, 90, 80, vv)?

Nếu tôi đã chèn 1.000.000 hàng mỗi ngày thì sao?

Tôi xin lỗi vì tất cả các câu hỏi, nhưng tôi đang tìm một số bản sao lưu để không sử dụng GUID làm mặc định cho PK. Tuy nhiên, tôi hoàn toàn cởi mở với tâm trí của tôi thay đổi bởi kiến ​​thức overwehlming từ cơ sở người dùng StackOverflow.

Answer 1

Nếu bạn đang làm bất kỳ loại âm lượng nào, GUID cực kỳ tệ khi PK xấu trừ khi bạn sử dụng sequential GUIDs, vì lý do chính xác bạn mô tả. Page fragmentation is severe:

    Average     Average 
       Fragmentation Fragment Fragment Page  Average 
Type    in Percent  Count  Size  Count Space Used 

id    4.35   7   16.43  115  99.89 
newidguid  98.77   162   1   162  70.90 
newsequentualid 4.35   7   16.43  115  99.89 

Và như this comparison giữa GUID và số nguyên cho thấy:

Test1 gây ra một lượng lớn chia tách trang, và có mật độ quét xung quanh 12% khi tôi chạy một DBCC SHOWCONTIG sau các chèn đã hoàn thành. Bảng Test2 có mật độ quét khoảng 98%

Nếu khối lượng của bạn rất thấp, tuy nhiên, nó không quan trọng lắm.

Nếu bạn thực sự cần một ID duy nhất trên toàn cầu nhưng có khối lượng lớn (và không thể sử dụng ID tuần tự), chỉ cần đặt GUID trong cột được lập chỉ mục.

Answer 2

Nhược điểm của việc sử dụng GUID như khóa chính:

• Không trật tự có ý nghĩa, có nghĩa là chỉ mục không cho hiệu suất tăng như nó với một số nguyên.
• Kích thước của GUID 16 byte, so với 2, 4 hoặc 8 byte cho số nguyên.
• Rất khó để con người nhớ, vì vậy không tốt như một id tham chiếu.

Ưu điểm:

• phép phi đoán khóa chính vì thế mà có thể ít nguy hiểm khi được hiển thị trong một chuỗi truy vấn trang web hoặc trong ứng dụng.
• Có ích trong Cơ sở dữ liệu không cung cấp loại dữ liệu nhận dạng tự động hoặc tăng dần.
• Hữu ích khi bạn cần kết hợp dữ liệu giữa hai nguồn dữ liệu khác nhau trên nền tảng hoặc môi trường.

Tôi nghĩ rằng quyết định về việc sử dụng GUID có khá đơn giản hay không, nhưng có lẽ tôi không biết các vấn đề khác.

Answer 3

Với số lần chèn thấp như vậy mỗi ngày, tôi nghi ngờ rằng việc tách trang phải là một yếu tố quan trọng. Câu hỏi thực sự là làm thế nào để so sánh 5.000 với số hàng hiện có, vì đây sẽ là thông tin chính cần thiết để quyết định một yếu tố điền ban đầu thích hợp để phân tách bớt.

Điều này nói rằng, cá nhân tôi không phải là một fan hâm mộ lớn của GUID. Tôi hiểu rằng họ có thể phục vụ tốt trong một số bối cảnh nhưng trong nhiều trường hợp, họ chỉ là "theo cách" [hiệu quả, dễ sử dụng, ...]

Tôi thấy các câu hỏi sau hữu ích để thu hẹp quyết định liệu GUID có nên được sử dụng hay không.

• PK có được chia sẻ/xuất bản không? (Tức là nó sẽ được sử dụng ngoài sử dụng nội bộ của mình trong SQL, các ứng dụng sẽ cần các phím này một cách hơi dai dẳng? Sẽ người dùng bằng cách nào đó nhìn thấy những phím?
• thể PK được sử dụng để giúp hợp nhất các nguồn dữ liệu khác nhau?
• Bảng có một kết hợp chính -possibly-làm từ cột (s) trong dữ liệu? Kích thước của điều này có thể phím này
• Làm thế nào để các phím chính sắp xếp?Nếu tổng hợp, có phải vài cột đầu tiên có chọn lọc không?

Answer 4

Sử dụng một guid (trừ khi nó là một GUID tuần tự) vì chỉ mục nhóm sẽ giết hiệu suất chèn. Vì bố cục bảng vật lý được căn chỉnh theo chỉ số nhóm, sử dụng một guid có thứ tự sắp xếp ngẫu nhiên sẽ gây ra sự phân mảnh bảng nghiêm trọng. Nếu bạn muốn sử dụng một guid như là một chỉ mục PK/Clustered nó phải là một guid tuần tự bằng cách sử dụng hàm newsequentialid() trong máy chủ sql. Điều này sẽ đảm bảo rằng các guids được tạo ra được sắp xếp tuần tự và ngăn chặn sự phân mảnh.