Một hay hai chỉ số?


11

Tôi có chỉ mục sau được tạo trên một bảng trong cơ sở dữ liệu của mình:

CREATE INDEX [idx_index1]
on [table1]
(col1, col2, col3)

Máy chủ đang đề xuất chỉ mục 'mất tích' sau đây:

CREATE INDEX [idx_index2]
on [table1]
(col1, col2)
INCLUDE (col3, col4, col5, col6....)

Tôi có vẻ hợp lý khi sửa đổi định nghĩa chỉ mục hiện có để bao gồm các cột được đề xuất, thay vì tạo một chỉ mục mới cần được duy trì. Một truy vấn chọn trên col1 và col2 có thể sử dụng index1 hiệu quả như index2. Tôi có đúng hay tôi có thể thiếu một cái gì đó?

Câu trả lời:


12

Và vì vậy, bước vào nghệ thuật điều chỉnh hiệu suất và chiến lược lập chỉ mục ...

Nó có vẻ hợp lý với tôi để sửa đổi định nghĩa chỉ mục hiện có để bao gồm các cột được đề xuất

Tôi sẽ lấy trích dẫn của bạn và viết định nghĩa chỉ mục thứ ba:

create index [idx_index3]
on [table1] (col1, col2, col3)
include (col4, col5, col6....);

Đó phải là CREATE INDEXtuyên bố tương ứng với tuyên bố được trích dẫn của bạn.

Điều đó rất tốt có thể là một giải pháp thận trọng, nhưng nó phụ thuộc . Dưới đây là một vài ví dụ khi tôi nói rằng nó phụ thuộc.

Nếu bạn có một khối lượng công việc chung bao gồm hầu hết các truy vấn như thế này:

select col1, col2, col3
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

Sau đó, idx_index1chỉ số của bạn sẽ được vững chắc. Hoàn toàn hẹp, đó là một chỉ mục thỏa mãn truy vấn đó mà không có dữ liệu không liên quan trong đó (không tính đến định nghĩa chỉ mục được nhóm, nếu có).

Nhưng nếu bạn có khối lượng công việc bao gồm các truy vấn chủ yếu như sau:

select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2;

Sau đó, idx_index2sẽ là khôn ngoan, vì đó là thứ được gọi là chỉ số che phủ ngăn chặn sự cần thiết phải tra cứu chính trở lại chỉ mục được nhóm (hoặc tìm kiếm RID trở lại heap). Định nghĩa chỉ mục không bao gồm đó sẽ chỉ bao gồm tất cả dữ liệu mà truy vấn cần.

Với đề xuất của bạn, nó sẽ rất phù hợp cho một truy vấn như sau:

select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

idx_index3Đề xuất của bạn sẽ là một chỉ số bao trùm đáp ứng các tiêu chí tìm kiếm cho truy vấn trên.

Điểm tôi đang cố gắng hiểu, là trong một câu hỏi biệt lập như thế này, chúng ta không thể trả lời dứt khoát điều này. Tất cả phụ thuộc vào khối lượng công việc phổ biến và thường xuyên là gì. Tất nhiên, bạn luôn có thể xác định cả ba chỉ mục này để xử lý từng loại truy vấn mẫu, nhưng sau đó sẽ đặt câu hỏi về việc bảo trì sẽ được yêu cầu để giữ cho các chỉ mục này được cập nhật (nghĩ: CHERTN, CẬP NHẬT, XÓA). Đó là chi phí chung của các chỉ số.

Bạn cần mổ xẻ và đánh giá khối lượng công việc, và xác định nơi nào có lợi thế tốt nhất. Nếu truy vấn mẫu đầu tiên là phổ biến nhất cho đến nay được thực hiện hàng chục lần một giây và có một truy vấn rất không thường xuyên như truy vấn mẫu thứ ba, thì sẽ không có ý nghĩa làm mờ các trang cấp độ lá của chỉ mục với INCLUDEcột nonkey. Tất cả phụ thuộc vào khối lượng công việc của bạn.

Nếu bạn hiểu các chiến lược lập chỉ mục thận trọng và bạn hiểu khối lượng công việc chung của mình, thì bằng cách áp dụng cả hai chiến lược đó, bạn sẽ có thể đưa ra lộ trình tốt nhất để thực hiện.


Tôi sẽ phải tiêu hóa nó trong một thời gian nhưng có vẻ như đó là một câu trả lời tốt. Tôi giả sử đó là một lỗi đánh máy rằng 'index3' mà bạn đã xác định có col3 là cột bình đẳng VÀ cột bao gồm?
paulH

Đúng :-) Bắt tốt. Tôi đã chỉnh sửa nó ra.
Thomas Stringer

Chưa kể rằng nếu bảng chỉ có cols 1-6 thì thật là ngớ ngẩn khi lập chỉ mục 1 & 2 và bao gồm 3-5.
Kenneth Fisher

1
@KennethFisher - tại sao điều đó thật ngớ ngẩn? Có vẻ như một điều đủ hợp lý để làm nếu cấu trúc cơ sở dữ liệu và khối lượng công việc của bạn đảm bảo nó. Ví dụ: nếu bạn có một truy vấn chọn các cột 1-5 dựa trên các giá trị của cột 1 và 2 và có thể cột 6 là cột nvarchar (tối đa) mà bạn không muốn làm mờ chỉ mục của mình.
paulH

1
@paulH Có lẽ đó chỉ là ý kiến ​​của tôi, nhưng tại thời điểm bạn đã thêm đủ các cột để bao gồm rằng chỉ mục của bạn có 90 +% số cột của bạn trong bảng, bạn đã đọc chỉ mục của mình đến điểm mà đọc thêm để đi đến bảng bản thân nó không quan trọng Bây giờ chắc chắn có ngoại lệ .. nếu cols 1-5 đều là int và col6 là varchar (max) thì tôi có thể làm điều đó. Nhưng nói chung tôi sẽ xem xét những RẤT cẩn thận.
Kenneth Fisher

7

Bạn thực sự đúng và đã phát hiện ra lý do tại sao một DBA luôn luôn xem xét các "đề xuất" được đưa ra bởi các DMV chỉ số bị thiếu, v.v.

Hãy xem xét rằng các đề xuất được cung cấp bởi các DMV chỉ mục bị thiếu được đưa ra một cách cô lập, có nghĩa là SQL Server đã quyết định rằng một chỉ mục của cấu trúc được đề xuất sẽ có lợi cho truy vấn, bất kể cấu trúc chỉ mục nào khác có thể tồn tại.


3

Một chút nữa, về một trong những hàm ý của câu trả lời của Thomas:

Anh nói:

Tất nhiên, bạn luôn có thể xác định cả ba chỉ mục này để xử lý từng loại truy vấn mẫu, nhưng sau đó sẽ đặt câu hỏi về việc bảo trì sẽ được yêu cầu để giữ cho các chỉ mục này được cập nhật (nghĩ: CHERTN, CẬP NHẬT, XÓA). Đó là chi phí chung của các chỉ số.

Vì vậy, một câu hỏi lớn khác trở thành: bảng thường xuyên được cập nhật như thế nào?

Trước tiên hãy xem xét một ví dụ về một bảng cập nhật liên tục , ví dụ như ORDERSbảng bán lẻ phản ánh hoạt động của người tiêu dùng trang web ... ở đó, bạn muốn có ý thức về việc có nhiều chỉ mục, bởi vì chúng làm tăng công việc được thực hiện bằng cách cập nhật liên tục, và do đó liên tục ảnh hưởng đến hiệu suất của cơ sở dữ liệu.

Mặt khác, hãy xem xét một bảng chỉ được cập nhật như một phần của thiết lập trang web - bảng được cập nhật ONCE cho hầu hết các giá trị và các giá trị được thêm không thường xuyên - ở đó, việc chậm cập nhật không được xem xét nhiều. Nhiều chỉ mục có thể làm chậm chỉ mục cơ sở dữ liệu xây dựng lại & reorgs, nhưng miễn là chúng đủ nhanh, CẢM NHẬN: nếu nhiều chỉ số tăng tốc độ đọc, hãy thực hiện.

Một trường hợp ở giữa có thể là một bảng thường chỉ được cập nhật trong một quy trình hàng loạt qua đêm. Ở đó, cập nhật sự chậm lại từ nhiều chỉ mục sẽ không ảnh hưởng đến hiệu suất ban ngày - chúng chỉ ảnh hưởng đến (1) thời gian thực hiện, để chạy bảo trì hàng đêm đó, (2) hiệu suất của bất kỳ quy trình đồng thời nào và (3) thời gian thực hiện nhiệm vụ bảo trì cơ sở dữ liệu như tổ chức lại chỉ mục. Vì vậy, miễn là các quy trình trong 3 đấu trường đó chạy đủ nhanh để bạn ... tạo các chỉ mục tăng tốc truy vấn.

HTH ...

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.