GUID có vẻ như là một lựa chọn tự nhiên cho khóa chính của bạn - và nếu bạn thực sự phải làm, bạn có thể tranh luận để sử dụng nó cho KHÓA CHÍNH của bảng. Điều tôi thực sự khuyên bạn nên không nên làm là sử dụng GUID làm khóa phân nhóm , SQL Server thực hiện theo mặc định, trừ khi bạn yêu cầu cụ thể là không.
Bạn thực sự cần phải tách biệt hai vấn đề:
-
khóa chính là một cấu trúc logic - một trong những khóa ứng cử viên xác định duy nhất và đáng tin cậy mọi hàng trong bảng của bạn. Đây có thể là bất cứ điều gì, thực sự - một
INT, mộtGUID, một chuỗi - chọn những gì có ý nghĩa nhất cho tình huống của bạn. -
khóa phân nhóm (cột hoặc các cột xác định "chỉ mục được nhóm" trên bảng) - đây là vật lý thứ liên quan đến lưu trữ và ở đây, loại dữ liệu nhỏ, ổn định, ngày càng tăng là lựa chọn tốt nhất của bạn -
INThoặcBIGINTlàm tùy chọn mặc định của bạn.
Theo mặc định, khóa chính trên bảng SQL Server cũng được sử dụng làm khóa phân cụm - nhưng điều đó không cần phải như vậy! Cá nhân tôi đã thấy hiệu suất tăng đáng kể khi chia khóa chính / cụm dựa trên GUID trước đó thành hai khóa riêng biệt - khóa chính (logic) trên GUID và khóa phân cụm (sắp xếp) trên một INT IDENTITY(1,1) riêng biệt cột.
Như Kimberly Tripp
- Nữ hoàng lập chỉ mục - và những người khác đã nói rất nhiều lần - GUID vì khóa phân cụm không tối ưu, do tính ngẫu nhiên của nó, nó sẽ dẫn đến phân mảnh trang và chỉ mục lớn và nói chung là hiệu suất kém.
Có, tôi biết - có newsequentialid() trong SQL Server 2005 trở lên - nhưng ngay cả điều đó cũng không thực sự và đầy đủ tuần tự và do đó cũng gặp phải các vấn đề tương tự như GUID - chỉ kém nổi bật hơn một chút.
Sau đó, có một vấn đề khác cần xem xét:khóa phân cụm trên bảng sẽ được thêm vào từng mục nhập trên mỗi và mọi chỉ mục không được phân cụm trên bảng của bạn - vì vậy bạn thực sự muốn đảm bảo rằng nó càng nhỏ càng tốt. Thông thường, một INT với hơn 2 tỷ hàng sẽ là đủ cho phần lớn các bảng - và so với GUID là chìa khóa phân cụm, bạn có thể tiết kiệm cho mình hàng trăm MB dung lượng lưu trữ trên đĩa và trong bộ nhớ máy chủ.
Tính toán nhanh - sử dụng INT so với GUID làm khóa chính và khóa phân cụm:
- Bảng cơ sở với 1'000'000 hàng (3,8 MB so với 15,26 MB)
- 6 chỉ mục không phân biệt (22,89 MB so với 91,55 MB)
TỔNG CỘNG:25 MB so với 106 MB - và đó chỉ là trên một bàn duy nhất!
Thêm một số thức ăn cho sự suy nghĩ - những thứ tuyệt vời của Kimberly Tripp - hãy đọc nó, đọc lại nó, hãy tiêu hóa nó! Đó thực sự là phúc âm lập chỉ mục của SQL Server.
- HƯỚNG DẪN làm KHÓA CHÍNH và / hoặc khóa nhóm
- Cuộc tranh luận về chỉ mục theo nhóm vẫn tiếp tục
- Khóa phân nhóm ngày càng tăng - Cuộc tranh luận về chỉ mục được phân cụm .......... một lần nữa!
- Dung lượng đĩa rẻ - điều đó không quan trọng!
Trừ khi bạn có lý do chính đáng , Tôi sẽ tranh luận để sử dụng INT IDENTITY đối với hầu hết mọi bảng dữ liệu "thực" làm mặc định cho khóa chính của chúng - nó là duy nhất, nó ổn định (không bao giờ thay đổi), nó hẹp, nó ngày càng tăng - tất cả các thuộc tính tốt mà bạn muốn có trong khóa phân cụm để có hiệu suất nhanh và đáng tin cậy cho các bảng SQL Server của bạn!
Nếu bạn có một số giá trị khóa "tự nhiên" cũng có tất cả các thuộc tính đó, thì bạn cũng có thể sử dụng giá trị đó thay vì khóa thay thế. Nhưng hai chuỗi có độ dài thay đổi của giá trị tối đa 20 ký tự mỗi ký tự không đáp ứng các yêu cầu đó theo ý kiến của tôi.
