Chỉ mục SQL Server nào nên được nhóm lại?

Question

Tôi có một số chỉ mục trên một số bảng, tất cả đều giống nhau và tôi muốn biết liệu chỉ mục Clustered có nằm đúng cột hay không. Dưới đây là số liệu thống kê từ hai chỉ số tích cực nhất:

Nonclustered 
I3_Identity (bigint) 
rows: 193,781 
pages: 3821 
MB: 29.85 
user seeks: 463,355 
user_scans: 784 
user_lookups: 0 
updates: 256,516 

Clustered Primary Key 
I3_RowId (varchar(80)) 
rows: 193,781 
pages: 24,289 
MB: 189.76 
user_seeks: 2,473,413 
user_scans: 958 
user_lookups: 463,693 
updates: 2,669,261 

Như bạn có thể thấy, PK đang được seeked thường, nhưng tất cả các tìm kiếm cho cột i3_identity đang làm tra cứu chìa khóa để này PK là tốt, rất là Tôi thực sự hưởng lợi từ chỉ số trên I3_Identity nhiều ở tất cả? Tôi có nên thay đổi để sử dụng I3_Identity như nhóm không? Điều này có thể có một tác động rất lớn khi cấu trúc bảng này được lặp lại khoảng 10000 lần mà tôi làm việc, vì vậy bất kỳ trợ giúp nào cũng sẽ được đánh giá cao.

Answer 1

Frederik tóm tắt nó một cách độc đáo, và đó thực sự là những gì Kimberly Tripp cũng thuyết giảng: phím phân cụm phải ổn định (không bao giờ thay đổi), bao giờ tăng (IDENTITY INT), nhỏ và độc đáo.

Trong trường hợp của bạn, tôi muốn đặt khóa cụm vào cột BIGINT thay vì cột VARCHAR (80).

Trước hết, với cột BIGINT, thật dễ dàng để thực thi tính duy nhất (nếu bạn không thực thi và đảm bảo tính duy nhất, SQL Server sẽ thêm 4 byte "uniquefier" vào mỗi hàng của bạn) và nó nhỏ hơn trung bình so với VARCHAR (80).

Tại sao kích thước lại quan trọng? Khóa phân cụm cũng sẽ được thêm vào MACHI và mọi chỉ mục không được nhóm của bạn - vì vậy nếu bạn có nhiều hàng và nhiều chỉ mục không được nhóm, có 40-80 byte so với 8 byte có thể nhanh chóng tạo ra một HUGE Sự khác biệt. Ngoài ra, một mẹo hiệu suất khác: để tránh cái gọi là tra cứu bookmark (từ một giá trị trong chỉ mục không nhóm của bạn thông qua các phím phân cụm vào các trang lá dữ liệu thực tế), SQL Server 2005 đã giới thiệu khái niệm "các cột được bao gồm" trong các chỉ mục không được nhóm của bạn. Đó là những điều cực kỳ hữu ích và thường bị bỏ qua. Nếu các truy vấn của bạn thường yêu cầu các trường chỉ mục cộng với một hoặc hai trường khác từ cơ sở dữ liệu, hãy xem xét các trường đó để đạt được cái được gọi là "các chỉ mục bao trùm". Một lần nữa - xem bài viết tuyệt vời của Kimberly Tripp - cô ấy là Nữ thần lập chỉ mục SQL Server! :-) và cô ấy có thể giải thích rằng công cụ tốt hơn nhiều so với tôi có thể ...

Vì vậy, để tổng hợp: hãy đặt khóa phân cụm của bạn trên một cột nhỏ, ổn định, độc đáo - và bạn sẽ làm tốt!

Marc

Answer 2

Từ những gì tôi đã đọc trong quá khứ, hai trong số các biện pháp quan trọng nhất liên quan đến lập chỉ mục bảng là số truy vấn được thực hiện đối với chỉ mục và mật độ chỉ mục. Bằng cách sử dụng DBCC_SHOWSTATISTICS ([bảng], [chỉ mục]), bạn có thể kiểm tra mật độ chỉ mục. Ý tưởng là bạn muốn chỉ mục nhóm của bạn trên các cột cung cấp sự khác biệt nhất cho mỗi truy vấn.

Tóm lại, nếu bạn nhìn vào thước đo "Tất cả mật độ" từ DBCC SHOW_STATISTICS và nhận thấy số lượng rất thấp, đây là chỉ số tốt để nhóm. Nó có ý nghĩa hợp lý để nhóm trên một chỉ mục cung cấp tính độc đáo hơn, nhưng chỉ khi nó được truy vấn tích cực. Clustering trên một chỉ số hiếm khi được sử dụng có thể sẽ làm hại nhiều hơn tốt.

Cuối cùng, đó là cuộc gọi phán xét. Bạn có thể muốn nói chuyện với DBA của bạn và phân tích mã của bạn để xem nơi bạn sẽ nhận được lợi ích lớn nhất. Trong ví dụ giới hạn này, việc lập chỉ mục của bạn dường như được nhóm lại ở khu vực bên phải nếu bạn chỉ xem xét việc sử dụng (và ngay cả khi bạn xem xét tất cả mật độ, với thực tế là khóa chính cung cấp tính độc đáo nhất mà bạn có thể tập hợp.)

Sửa : Có một bài viết khá hay về MSDN giải thích những gì SHOW_STATISTICS cung cấp cho bạn. Tôi chắc chắn không phải là một DBA uber, nhưng hầu hết các thông tin tôi đã cung cấp ở đây đến từ hướng dẫn đưa ra bởi DBA của chúng tôi :)

Dưới đây là bài viết: http://msdn.microsoft.com/en-us/library/ms174384.aspx

Answer 3

Here's the best discussion tôi đã tìm thấy về chủ đề. Kimberly Tripp là một blogger MS ở trên đỉnh của cuộc tranh luận. Tôi có thể giải thích nó cho bạn, nhưng bạn rõ ràng là hiểu được các từ và khái niệm cơ bản, và bài viết rất dễ đọc. Vì vậy, tận hưởng!

Gợi ý: bạn sẽ thấy rằng các câu trả lời ngắn hầu như luôn quá đơn giản.

Answer 4

nhanh 'n bẩn:

Đặt clustered index trên:

• một cột người là giá trị (gần như) không bao giờ thay đổi

• một cột mà giá trị trên các hồ sơ mới tăng/giảm theo tuần tự

• một cột nơi bạn thực hiện phạm vi - tìm kiếm

Answer 5

Nói chung, khi tôi thấy tra cứu khóa cho khóa chính/cụm, có nghĩa là tôi cần bao gồm (sử dụng câu lệnh INCLUDE) nhiều cột trong khóa không được nhóm. Xem các truy vấn của bạn và xem những cột nào đang được chọn/sử dụng trong các câu lệnh đó. Nếu bạn bao gồm các cột đó trong khóa không được nhóm, thì sẽ không cần phải thực hiện tra cứu khóa nữa.