Tại thời điểm nào có một chỉ số trở nên hiệu quả

Tôi đã tìm thấy rất nhiều tài nguyên đề cập rằng việc thêm chỉ mục vào bảng sẽ giúp tìm kiếm nhanh hơn và chèn chậm hơn, nhưng chỉ khi bảng lớn. Điều này tạo ra một sự đánh đổi, đó là một quyết định thiết kế, nhưng cần có một kích thước bảng gần đúng trước khi sử dụng một chỉ mục là vô lý. (Ví dụ, 10 hàng có thể nằm dưới giới hạn đó)

Có ai biết giới hạn này sẽ ở đâu, hoặc biết về một tài nguyên sẽ chỉ cho tôi đi đúng hướng không?

Giới hạn chính xác là rất khó để xác định trước thời hạn.

Một điều mà hầu hết mọi người đánh giá thấp là các yêu cầu cao mà một chỉ mục phải đáp ứng, trước khi nó trở thành một ứng cử viên được sử dụng trong truy vấn.

Một chỉ số hiệu quả (không bao gồm)

• cung cấp tính chọn lọc tuyệt vời , ví dụ chỉ trả về một tỷ lệ rất nhỏ (<1%, <2%) trong tổng số hàng. Nếu tính chọn lọc không phải là nhất định - trình tối ưu hóa truy vấn của SQL Server rất có thể sẽ bỏ qua chỉ mục này

• lý tưởng nên bao gồm truy vấn, tức là trả về tất cả các cột theo yêu cầu của truy vấn. Nếu bạn có thể tạo một chỉ mục có 1 hoặc 2 cột chỉ mục và bao gồm một số cột (2-4) khác như các cột được bao gồm và do đó bạn có thể bao gồm một truy vấn - thì rất có thể trình tối ưu hóa truy vấn sẽ sử dụng chỉ mục này. Điều đó cũng có nghĩa là: nếu mã của bạn luôn được sử dụng SELECT * .....để tìm nạp tất cả các cột , thì khả năng các chỉ số được sử dụng sẽ giảm xuống - thực sự rất đáng kể

Tôi chắc chắn cũng có rất nhiều tiêu chí khác - nhưng tôi sẽ tin rằng hai tiêu chí này là những tiêu chí quan trọng nhất. Tất nhiên, bạn phải luôn luôn duy trì các chỉ số của mình được duy trì đúng cách (sắp xếp lại, xây dựng lại) và đảm bảo các số liệu thống kê liên quan đến các chỉ số của bạn được cập nhật.

PS: các chỉ số không bao gồm trên các cột khóa ngoại là một trường hợp đặc biệt; theo mặc định, tôi luôn khuyên bạn nên thêm chúng, vì chúng giúp tăng tốc cả kiểm tra tính toàn vẹn tham chiếu, cũng như JOINcác ràng buộc FK đó. Nhưng ngay cả ở đây, nó hoàn toàn hợp lệ để "mở rộng" các chỉ số cột FK đó bằng cách thêm một số cột "bao gồm" bổ sung để làm cho chúng hữu ích hơn nữa.

Bạn có thể thấy một sự cải thiện từ một chỉ mục chỉ có 10 hàng.

Trong thử nghiệm sau trên máy của tôi, phiên bản không có chỉ mục hoàn thành sau 10.5vài giây và phiên bản có chỉ mục tính bằng 9.8giây (nhất quán trên 3 lần chạy).

Chỉ mục trong trường hợp này chỉ bao gồm 1 trang lá nhưng vì mảng vị trí được sắp xếp theo thứ tự khóa chỉ mục, sự hiện diện của nó cho phép SQL Server chỉ trả về một hàng quan tâm thay vì thực hiện tổng hợp trên cả 10.

CREATE TABLE T
(
X INT,
Y CHAR(100) NULL
)

INSERT INTO T (X)
SELECT number 
FROM master..spt_values
WHERE type='P' AND number BETWEEN 1 AND 10

set nocount on;

DECLARE @I INT, @X INT

DECLARE @Time DATETIME2(7) = SYSUTCDATETIME()

SET @I = 1
    WHILE (@I < 1000000)
    BEGIN
    SELECT @X = MAX(X)
    FROM T
    SET @I += 1
    END

SELECT DATEDIFF(MICROSECOND, @Time, SYSUTCDATETIME())

CREATE CLUSTERED INDEX IX ON T(X)
SET @Time = SYSUTCDATETIME()
SET @I = 1
    WHILE (@I < 1000000)
    BEGIN
    SELECT @X = MAX(X)
    FROM T
    SET @I += 1
    END

SELECT DATEDIFF(MICROSECOND, @Time, SYSUTCDATETIME())

DROP TABLE T