Mã định danh duy nhất (guid) làm khóa chính trong thiết kế cơ sở dữ liệu

Question

Dữ liệu của chúng tôi nằm trong cơ sở dữ liệu SQL Server 2008, sẽ có nhiều truy vấn và kết nối giữa các bảng. Chúng tôi có lập luận này bên trong nhóm, một số tranh luận sử dụng danh tính nguyên là tốt hơn cho hiệu suất, một số đang tranh luận sử dụng guid (định danh duy nhất).

Hiệu suất thực sự có ảnh hưởng xấu đến việc sử dụng GUID làm khóa chính không?

Answer 1

Phím GUID 128 bit (uniqueidentifier) tất nhiên là 4x lớn hơn khóa 322 bit int 32 bit. Tuy nhiên, có một vài ưu điểm nổi bật:

• Không "SẮC INSERT" vấn đề khi sáp nhập nội dung
• Nếu bạn sử dụng một giá trị COMB thay vì NEWSEQUENTIALID(), bạn sẽ có được một "miễn phí" INSERT dấu thời gian. Bạn thậm chí có thể SELECT từ khóa chính dựa trên phạm vi ngày/giờ nếu bạn muốn với một số cuộc gọi ưa thích CAST().
• Chúng độc đáo trên toàn cầu, hóa ra khá tiện dụng ngay bây giờ và sau đó.
• Vì không cần phải theo dõi dấu vết nước cao, lớp BL của bạn có thể gán 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 thậm chí bạn có thể có hơn 2 tỷ bản ghi từ xa, bạn cần phải sử dụng bigint (64 bit) thay vì int. Khi bạn làm điều đó, uniqueidentifier chỉ lớn gấp đôi số bigint.
• Sử dụng GUID giúp an toàn hơn khi hiển thị các khóa trong URL, v.v. mà không tự phơi bày các cuộc tấn công "đoán-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. Bài kiểm tra cuối cùng tôi thấy cho thấy GUID gần như nhanh.
• Kích thước chỉ mục phụ thuộc vào bao gồm cột được bao gồm. Mặc dù bản thân GUID là 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, ép ra một số lợi thế hiệu suất nhỏ bằng cách sử dụng các số nguyên có thể không đáng để mất các ưu điểm của GUID. Kiểm tra nó theo kinh nghiệm và quyết định cho chính mì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ự đi xuống hiệu suất trong trường hợp của tôi.

Answer 2

Ưu điểm chính của việc sử dụng GUID là chúng là duy nhất trên tất cả không gian và thời gian.

Những bất lợi chính khi sử dụng GUID làm giá trị khóa là chúng là LỚN. Với 16 byte một pop, chúng là một trong những kiểu dữ liệu lớn nhất trong SQL Server. Các chỉ mục được xây dựng trên GUID sẽ lớn hơn và chậm hơn các chỉ mục được xây dựng trên các cột IDENTITY, thường là ints (4 byte).

Vì vậy, họ là một giải pháp tốt cho các trường hợp khi bạn cần phải kết hợp dữ liệu từ nhiều nguồn

Nguồn: http://www.sqlteam.com/article/uniqueidentifier-vs-identity

Answer 3

Những bài báo về vấn đề này mà tôi có trong bookmark của tôi: http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/guid-vs-int-debate.aspx

Answer 4

Cá nhân tôi sử dụng INT IDENTITY cho hầu hết các khóa chính và phân cụm của tôi.

Bạn cần phải giữ ngoài các chính chủ chốt mà là một cấu trúc logic - nó xác định duy nhất hàng của bạn, nó phải là duy nhất và ổn định và NOT NULL. GUID cũng hoạt động tốt cho khóa chính - vì nó được đảm bảo là duy nhất. GUID là khóa chính của bạn là một lựa chọn tốt nếu bạn sử dụng bản sao SQL Server, vì trong trường hợp đó, bạn cần một cột GUID duy nhất để xác định.

Phím phân cụm trong SQL Server là một cấu trúc vật lý được sử dụng cho thứ tự vật lý của dữ liệu và rất khó để có được quyền. Thông thường, Nữ hoàng lập chỉ mục trên SQL Server, Kimberly Tripp, cũng yêu cầu một khóa phân cụm tốt để được uniqe, ổn định, càng hẹp càng tốt, và lý tưởng bao giờ tăng (tất cả đều là INT IDENTITY).

Xem bài viết của mình trên lập chỉ mục ở đây:

• GUIDs as PRIMARY KEYs and/or the clustering key
• The Clustered Index Debate Continues...
• Ever-increasing clustering key - the Clustered Index Debate..........again!

và cũng thấy The Cost of GUIDs as Primary Key

Một GUID Jimmy Nilsson là một sự lựa chọn khủng khiếp xấu cho một cluste vòng chìa khóa, vì nó rộng, hoàn toàn ngẫu nhiên, và do đó dẫn đến phân mảnh chỉ mục xấu và hiệu suất kém. Ngoài ra, các hàng khóa cụm (s) cũng được lưu trữ trong mỗi và mọi mục nhập của mỗi và tất cả các nhóm (bổ sung) chỉ mục, vì vậy bạn thực sự muốn giữ nó nhỏ - GUID là 16 byte so với INT là 4 byte, và với một số chỉ số không nhóm và vài triệu hàng, điều này tạo ra sự khác biệt HUGE.

Trong SQL Server, khóa chính của bạn theo mặc định là khóa phân cụm - nhưng không nhất thiết phải như vậy. Bạn có thể dễ dàng sử dụng GUID làm khóa chính không được nhóm, và INT IDENTITY làm khóa phân cụm của bạn - nó chỉ mất một chút ý thức về nó.

Answer 5

Vấn đề lớn với GUID là khóa chính là chúng tạo ra phân mảnh bảng lớn, có thể là vấn đề hiệu suất lớn (bảng lớn hơn, vấn đề lớn hơn). Ngay cả như một chìa khóa cho một chỉ số nonclustered, họ sẽ gây ra phân mảnh chỉ mục.

Bạn có thể giảm thiểu một phần vấn đề bằng cách đặt yếu tố lấp đầy phù hợp - nhưng nó vẫn sẽ là một vấn đề.

Sự khác biệt về kích thước không làm phiền tôi nhiều, ngoại trừ trên các bảng có các hàng hẹp khác, nơi cũng cần quét bảng. Trong những trường hợp đó, việc có thể phù hợp với nhiều hàng hơn trên mỗi trang DB là một lợi thế hiệu suất.

Có thể có lý do chính đáng để sử dụng GUID, nhưng cũng có chi phí. Tôi thường thích INT IDENTITY cho các khóa chính, nhưng tôi không tránh GUID khi chúng là một giải pháp tốt hơn.

Answer 6

Nếu bản ghi bảng cơ sở dữ liệu có thể phát triển thành triệu bản ghi, tôi nghĩ rằng không nên sử dụng nó làm khóa chính.