Lý do không có chỉ mục nhóm trong SQL Server 2005

Question

Tôi đã thừa kế một số tập lệnh tạo cơ sở dữ liệu cho cơ sở dữ liệu SQL SERVER 2005.

Một điều tôi đã nhận thấy là tất cả các khóa chính được tạo dưới dạng NON CLUSTERED chỉ mục trái ngược với cụm.

Tôi biết rằng bạn chỉ có thể có một chỉ mục nhóm trên mỗi bảng và bạn có thể muốn có chỉ mục nhóm chính cho hiệu suất truy vấn tìm kiếm, v.v. Tuy nhiên, không có chỉ mục nào khác trên bảng trong câu hỏi.

Vì vậy, câu hỏi của tôi là có bất kỳ lý do kỹ thuật nào không có chỉ mục nhóm trên cột khóa chính ngoài các phần trên.

Answer 1

Trên bất kỳ bảng tra cứu hoặc dữ liệu "bình thường" nào: không, tôi không thấy bất kỳ lý do gì.

Trên các công cụ như bảng nhập hàng loạt hoặc bảng tạm thời - tùy thuộc vào.

Đối với một số người ngạc nhiên, có vẻ như có một chỉ số nhóm tốt thực sự có thể tăng tốc các hoạt động như INSERT hoặc UPDATE. Xem Kimberly Tripps xuất sắc The Clustered Index Debate continues.... bài đăng trên blog mà trong đó cô giải thích chi tiết về lý do tại sao lại xảy ra trường hợp này.

Trong ánh sáng này: Tôi không thấy bất kỳ lý do chính đáng không có một nhóm chỉ số tốt (hẹp, ổn định, độc đáo, ngày càng tăng = INT IDENTITY là sự lựa chọn rõ ràng nhất) trên bất kỳ bảng SQL Server .

Để có được một số hiểu biết sâu vào như thế nào và tại sao để lựa chọn phím clustering, đọc tất cả các bài đăng trên blog xuất sắc Kimberly Tripp về chủ đề này:

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustering-Key.aspx

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustered-Index.aspx

xuất sắc thứ từ "nữ hoàng lập chỉ mục "!:-)

Answer 2

Clustered Tables vs Heap Tables

(Tốt bài viết về đề tài này tại www.mssqltips.com)

Heap Table (Nếu không có clustered index)

• dữ liệu không được lưu trữ trong bất kỳ đặc biệt trật tự

• Dữ liệu cụ thể c một không được lấy ra một cách nhanh chóng, nếu không có cũng là chỉ số không clustered

• trang dữ liệu không liên kết, vì vậy truy cập tuần tự cần phải xem lại vào bản đồ phân bổ chỉ mục (IAM) trang

• Vì không có chỉ số clustered, thêm thời gian là không cần thiết để duy trì chỉ số

• Vì không có chỉ số clustered, có được không th e cần cho thêm không gian để lưu trữ các chỉ số clustered cây

• Các bảng này có một giá trị index_id của 0 trong giao diện Danh mục sys.indexes

Clustered Bảng

• Dữ liệu được lưu trữ theo thứ tự dựa trên khóa chỉ mục được nhóm

• Dữ liệu có thể được lấy ra một cách nhanh chóng dựa trên phím clustered index, nếu truy vấn sử dụng các cột được đánh chỉ mục

• trang dữ liệu được liên kết cho nhanh truy cập tuần tự thời gian bổ sung là cần thiết để duy trì nhóm chỉ số dựa trên chèn, cập nhật và xóa

• không gian bổ sung là cần thiết để lưu trữ cụm cây index các bảng này có một giá trị index_id trong tổng số 1 trong danh mục sys.indexes xem

Answer 3

Đây là một câu hỏi khác (đã được cung cấp trong các câu trả lời khác chưa?) Lý do có thể (vẫn được hiểu):

• SQL Server - Poor performance of PK delete

Tôi hy vọng, tôi sẽ cập nhật sau nhưng bây giờ nó là khá mong muốn liên kết các chủ đề

Cập nhật:
What do I miss in understanding the clustered index?

Answer 4

Vui lòng đọc câu trả lời của tôi dưới "Không có quyền truy cập trực tiếp vào hàng dữ liệu trong bảng được nhóm - tại sao?", trước tiên. Cụ thể mục [2] Caveat.

Những người đã tạo "cơ sở dữ liệu" là cretin. Họ có:

• một loạt các spreadhseets unnormalised, không bảng quan hệ bình thường
• các PKS được tất cả cột SẮC (các bảng tính được liên kết với nhau, họ phải được điều hướng một-by-one- bởi một); không có quyền truy cập quan hệ hoặc điện quan hệ trên cơ sở dữ liệu
• họ đã PRIMARY KEY, sản xuất UNIQUE Clustered
• họ phát hiện ra rằng đó ngăn chặn đồng thời
• họ loại bỏ các CI và làm cho họ tất cả NCIS
• họ quá lười biếng để hoàn thành việc đảo ngược; đề cử một thay thế (hiện tại NCI) để trở thành CI mới, cho mỗi bảng
• cột IDENTITY vẫn là Primary Key (nó không phải là thực sự, nhưng nó là trong việc thực hiện tay vụng về này)

Đối với các bộ sưu tập các bảng tính giả mạo như cơ sở dữ liệu, nó ngày càng trở nên phổ biến hơn để tránh các CIs hoàn toàn, và chỉ có NCI cộng với Heap. Rõ ràng là họ không nhận được quyền lực hay lợi ích nào của CI, nhưng họ không nhận được quyền lực hay lợi ích của cơ sở dữ liệu quan hệ, vì vậy họ quan tâm rằng họ không có được sức mạnh của CIs (được thiết kế cho cơ sở dữ liệu quan hệ) không phải là). Cách họ nhìn vào nó, họ phải "refactor" những điều darn mọi như vậy thường anyway, vậy tại sao bận tâm. Cơ sở dữ liệu quan hệ không cần "tái cấu trúc".

Nếu bạn cần thảo luận thêm về phản hồi này, vui lòng đăng CREATE TABLE/INDEX DDL; bằng không nó là lập luận học thuật lãng phí thời gian.

Answer 5

Với một số máy chủ/ngôn ngữ lập trình b-tree vẫn được sử dụng ngày nay, các tệp ascii dài cố định hoặc biến đổi được sử dụng để lưu trữ dữ liệu. Khi một bản ghi/hàng dữ liệu mới được thêm vào một tệp (bảng), bản ghi là (1) được nối vào cuối tệp (hoặc thay thế một bản ghi đã xóa) và (2) các chỉ mục được cân bằng. Khi dữ liệu được lưu trữ theo cách này, bạn không phải lo lắng về hiệu năng hệ thống (theo như những gì mà máy chủ b-tree đang thực hiện để trả về một con trỏ tới bản ghi dữ liệu đầu tiên). Thời gian phản hồi chỉ được thực hiện bằng số nút trong tệp chỉ mục của bạn.

Khi bạn sử dụng SQL, bạn hy vọng sẽ nhận ra rằng hiệu năng hệ thống phải được xem xét bất cứ khi nào bạn viết một câu lệnh SQL. Sử dụng câu lệnh "ORDER BY" trên cột không được lập chỉ mục có thể mang một hệ thống đến đầu gối của nó. Sử dụng một chỉ số nhóm có thể đặt một tải không cần thiết trên CPU. Đó là thế kỷ 21 và tôi ước chúng ta không phải suy nghĩ về hiệu năng hệ thống khi lập trình trong SQL, nhưng chúng ta vẫn làm.

Với một số ngôn ngữ lập trình cũ hơn, bắt buộc phải sử dụng chỉ mục bất cứ khi nào dữ liệu được sắp xếp được truy lục. Tôi chỉ muốn yêu cầu này vẫn còn tại chỗ ngày hôm nay. Tôi chỉ có thể tự hỏi có bao nhiêu công ty đã cập nhật hệ thống máy tính chậm của họ do một câu lệnh SQL được viết kém trên dữ liệu không được lập chỉ mục.

Trong 25 năm lập trình, tôi chưa bao giờ cần dữ liệu vật lý của mình được lưu trữ theo thứ tự cụ thể, vì vậy có thể đó là lý do tại sao một số lập trình viên tránh sử dụng các chỉ mục nhóm. Thật khó để biết sự cân bằng là gì (thời gian lưu trữ, thời gian truy tìm câu) đặc biệt là nếu hệ thống bạn đang thiết kế có thể lưu trữ hàng triệu bản ghi vào một ngày nào đó.