Có phải 'Tránh tạo một chỉ mục được nhóm dựa trên khóa tăng' là một huyền thoại từ SQL Server 2000 ngày?

22

Cơ sở dữ liệu của chúng tôi bao gồm rất nhiều bảng, hầu hết trong số chúng sử dụng khóa thay thế số nguyên làm khóa chính. Khoảng một nửa số khóa chính này nằm trên các cột định danh.

Việc phát triển cơ sở dữ liệu bắt đầu từ thời SQL Server 6.0.

Một trong những quy tắc được tuân thủ ngay từ đầu là, Tránh tạo một chỉ mục được nhóm dựa trên khóa tăng dần , như bạn tìm thấy trong các Mẹo tối ưu hóa chỉ mục này .

Bây giờ sử dụng SQL Server 2005 và SQL Server 2008, tôi có ấn tượng mạnh mẽ rằng hoàn cảnh đã thay đổi. Trong khi đó, các cột khóa chính này là ứng cử viên đầu tiên hoàn hảo cho chỉ mục được nhóm của bảng.

sql-server sql-server-2005 clustered-index

— bernd_k
nguồn

34

Huyền thoại quay trở lại trước SQL Server 6.5, đã thêm khóa cấp hàng . Và gợi ý ở đây bởi Kalen Delaney .

Đó là để làm với "điểm nóng" của việc sử dụng trang dữ liệu và thực tế là toàn bộ trang 2k (SQL Server 7 và các trang 8k sử dụng cao hơn) đã bị khóa, thay vào đó là một hàng được chèn Chỉnh sửa, tháng 2 năm 2012

Tìm thấy bài viết có thẩm quyền của Kimberly L. Tripp

"Cuộc tranh luận về chỉ số cụm tiếp tục ..."

Điểm nóng là thứ mà chúng tôi đã cố gắng hết sức để tránh PRIOR cho SQL Server 7.0 vì khóa cấp độ trang (và đây là lúc điểm nóng trở thành thuật ngữ phủ định). Trong thực tế, nó không phải là một thuật ngữ tiêu cực. Tuy nhiên, do công cụ lưu trữ đã được tìm kiếm / thiết kế lại (trong SQL Server 7.0) và hiện bao gồm khóa cấp hàng thực sự, động lực này (để tránh các điểm nóng) không còn nữa.

Chỉnh sửa, tháng 5 năm 2013

Liên kết trong câu trả lời của lucky7_2000 dường như nói rằng các điểm nóng có thể tồn tại và chúng gây ra sự cố. Tuy nhiên, bài viết sử dụng một chỉ mục cụm không duy nhất trên TranTime. Điều này đòi hỏi một uniquifier được thêm vào. Điều đó có nghĩa là chỉ số không hoàn toàn tăng đơn điệu (và quá rộng). Liên kết trong câu trả lời đó không mâu thuẫn với câu trả lời này hoặc các liên kết của tôi

Ở cấp độ cá nhân, tôi đã đánh thức các cơ sở dữ liệu nơi tôi đã chèn hàng chục nghìn hàng mỗi giây vào một bảng có cột IDENTITY lớn như PK phân cụm.

— gbn
nguồn

23

Tóm lại, trong các phiên bản SQL Server hiện đại, khóa cụm trên cột nhận dạng là tùy chọn ưa thích hiện nay.

— mrdenny
nguồn

Ngắn gọn, đơn giản, đến mức điều này nhận được +1 của tôi. Hãy chắc chắn kiểm tra liên kết đến SQLSkills vì có rất nhiều thông tin tốt ở đó.

— AndrewQuery

12

Điều này nghe giống như một lệnh. Không có lời giải thích hay logic nào về lý do tại sao chúng ta nên ...

— gbn

Nó không chỉ nghe giống như một lệnh, nó cũng sai. Bất kỳ cơ sở dữ liệu nào có số lượng chèn / giây rất cao sẽ gặp phải các vấn đề về điểm nóng nếu bạn sử dụng các khóa liên tiếp.

— Thomas Kejser

1

Tôi nói ưa thích, không bắt buộc. Đối với các ứng dụng thông thường chiếm tới 98% cơ sở dữ liệu trên thế giới, một khóa cụm trên cột nhận dạng hoạt động tốt.

— mrdenny

10

Kimberly Tripp có một bài đăng blog tuyệt vời về chủ đề này. Tôi có thể diễn giải, nhưng tin tôi đi, tôi sẽ không làm điều đó công bằng. Có một đọc. http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx

Trong khi ở đó, hãy kiểm tra một số bài viết khác của cô ấy về chủ đề phân cụm. Có rất nhiều kiến thức cần có từ trang web của cô.

— Matt M
nguồn

4

kiểm tra bài này:

http://bloss.msdn.com/b/sqlserverfaq/archive/2010/05/27/monotonively-increasing-clustered-index-keys-can-cause-latch-contention.aspx

tạo một chỉ mục được nhóm dựa trên khóa tăng có thể tạo ra các điểm nóng có hại cho hiệu suất ...

— may mắn7_2000
nguồn

1

+1 để cung cấp liên kết đó. Có một số gợi ý thú vị ở đó. Nhưng tôi nghĩ rằng kết quả sẽ thuyết phục hơn nhiều, nếu anh ta so sánh kịch bản đã cho với kịch bản tạo chỉ mục không bao gồm cidx_trantime trên tblTransilities (TranTime) hoặc một số phương án khác. Hãy nhớ rằng khi bạn tạo ra nhiều dữ liệu như vậy, phải có những cách hiệu quả để lấy dữ liệu, bạn không thể ném mọi thứ vào một đống.

— bernd_k

@bernd_k: đây là một liên kết ví dụ kém. Bảng con có khóa phân cụm không duy nhất xấu yêu cầu một trình duy nhất nội bộ

— gbn

1

Hãy thử thí nghiệm này sau đó: kejser.org/boosting-insert-speed-by-generating-scalable-keys

— Thomas Kejser 6/2/2015