Bất kỳ lợi thế của việc có một chỉ mục thứ hai với các cột được bao gồm trên một khóa chính?

Tôi đang xem xét cơ sở dữ liệu của mình và nhận thấy rằng trên một bảng cụ thể, chúng tôi có các chỉ mục sau:

Bảng :

Col1    INT IDENTITY(1,1) Primary Key
Col2    INT
...
about 15 more columns
....
ColN   VARCHAR(50)
....
another 10 more columns

Ngoài chỉ mục cụm khóa chính tiêu chuẩn trên Col1, chúng tôi cũng có chỉ mục sau:

create nonclustered index [iTable-Col1] ON [dbo].[Table1]
(
    Col1
)
include ( ColN )

Chúng tôi thường xuyên tìm kiếm theo Col1và chỉ muốn lấy ColN. Chỉ mục này được sử dụng vì đây là chỉ mục nhỏ nhất chứa tất cả dữ liệu cần thiết để đáp ứng truy vấn.

Câu hỏi của tôi là, chỉ mục này có thêm bất kỳ lợi ích nào cho SQL Server không? Chúng ta sẽ tốt hơn nếu bỏ nó đi và chỉ thực hiện tìm kiếm trên chỉ mục cụm?

Tôi chỉ nghĩ rằng chỉ số này nhỏ hơn nhiều so với chỉ số được nhóm (25mb so với 300mb) có thể giúp tìm kiếm và / hoặc lưu trữ nhanh hơn.

Máy chủ là SQL Server 2012 nếu điều đó tạo ra sự khác biệt.

Hầu hết thời gian, loại chỉ mục này chỉ hữu ích cho việc quét chỉ mục đối với các cột đó.

Cấu trúc cây chỉ mục trên cấp độ lá thường sẽ rất giống nhau về cấp độ cây, vì vậy nếu là trường hợp đó, có rất ít hoặc không có sự khác biệt về hiệu suất trong việc điều hướng cây để tìm kiếm hoạt động (cũng không quét). Nếu bạn muốn tìm hiểu những điều cơ bản về chỉ số nội bộ, tôi có một video ở đây sẽ giúp bạn.

Dù sao, trở lại quét. Những lý do tại sao chỉ mục này sẽ hữu ích ít hơn nhiều về chính chỉ mục và nhiều hơn về lý do tại sao không quét chỉ mục được nhóm (hoặc giữ các trang dữ liệu đó trong bộ nhớ). Nếu các cột khác làm cho bảng tương đối rộng (dựa trên kích thước bạn đã cung cấp, tôi sẽ nói họ làm, mặc dù không rõ bảng này lớn đến mức nào trong bối cảnh của toàn bộ cơ sở dữ liệu), trong một số trường hợp , chỉ số hẹp có thể có ích . Quét thường xuyên (hoặc tìm kiếm trên nhiều giá trị khóa khác nhau) sẽ có xu hướng giữ toàn bộ chỉ mục trong bộ nhớ, vì vậy chỉ mục càng lớn, sẽ càng có ít không gian bộ nhớ cho các đối tượng khác và tất nhiên điều này sẽ phát sinh thêm I / O nếu bể đệm lạnh.

Mặc dù đó là một trường hợp sử dụng hiếm gặp (tôi đã thực hiện một lần hoặc có thể hai lần mà tôi có thể nhớ), nhưng lợi ích lớn nhất của loại chỉ mục này là nó sẽ giúp ích rất nhiều cho các truy vấn muốn sử dụng kết hợp để tham gia bảng này. (Lưu ý: trước tiên hãy tối ưu hóa truy vấn nếu quét chỉ mục không phù hợp!) Trong kế hoạch truy vấn, quét chỉ mục được nhóm hoặc quét và sắp xếp chỉ mục không được bao gồm trước khi kết hợp hợp nhất có thể cho biết khi nào điều này có thể là một ý tưởng tốt. Nhưng một lần nữa, điều này là hiếm. Truy vấn phải được thực hiện đủ thường xuyên hoặc bảng cơ sở đủ đắt để bị kẹt trong bộ nhớ (nghĩa là bạn không cần nó ở đó mọi lúc), để biện minh cho việc lưu trữ và bảo trì thêm cho chỉ mục.

Nếu bạn không chắc chắn làm thế nào chỉ số này đang được sử dụng ngay bây giờ, hãy kiểm tra DMV sys.dm_db_index_usage_stats. Hãy nhớ rằng số lượng được đặt lại khi khởi động lại máy chủ, vì vậy nếu bạn đang xem xét bỏ chỉ mục, hãy đảm bảo rằng nó không hữu ích trong toàn bộ chu kỳ kinh doanh .

Hãy để SQL Server trả lời câu hỏi của bạn, nếu chỉ mục hữu ích, Trình tối ưu hóa truy vấn sẽ sử dụng nó, nếu không thì nó sẽ không.