W jakim momencie posiadanie indeksu staje się skuteczne

Znalazłem wiele zasobów, które wspominają, że dodanie indeksu do tabeli przyspiesza wyszukiwanie i wstawia wolniej, ale tylko wtedy, gdy tabela jest duża. Stwarza to kompromis, który jest decyzją projektową, ale powinna istnieć przybliżona wielkość tabeli, przed którą użycie indeksu jest absurdalne. (Na przykład 10 wierszy jest prawdopodobnie znacznie poniżej tego limitu)

Czy ktoś wie, gdzie byłby ten limit, czy wie o zasobach, które wskazywałyby mi właściwy kierunek?

Dokładny limit jest naprawdę trudny do ustalenia z wyprzedzeniem.

Jedną z rzeczy, których większość ludzi nie docenia, są wysokie wymagania, które musi spełnić indeks, zanim stanie się on kandydatem do użycia w zapytaniu.

Wydajny (nieklastrowany) indeks

• oferuje doskonałą selektywność , np. zwraca tylko bardzo mały procent (<1%, <2%) wszystkich wierszy. Jeśli selektywność nie jest podana - optymalizator zapytań programu SQL Server najprawdopodobniej zignoruje ten indeks

• powinien idealnie obejmować zapytanie, tzn. zwrócić wszystkie kolumny wymagane przez zapytanie. Jeśli możesz utworzyć indeks, który ma 1 lub 2 kolumny indeksu i zawiera inne garści (2-4) kolumn jako uwzględnione kolumny, a tym samym możesz pokryć zapytanie - wtedy istnieje szansa, że ​​optymalizator zapytań użyje tego indeksu. Co oznacza również: jeśli Twój kod zawsze SELECT * .....pobiera wszystkie kolumny , prawdopodobieństwo użycia indeksów spada - w rzeczywistości dość dramatycznie

Jestem pewien, że istnieje również mnóstwo innych kryteriów - ale uważam, że te dwa są najbardziej krytyczne. Oczywiście, zawsze powinieneś utrzymywać swoje indeksy we właściwy sposób (reorganizować, przebudowywać) i upewnić się, że statystyki powiązane z Twoimi indeksami są aktualne.

PS: indeksy nieklastrowane w kolumnach z kluczami obcymi są przypadkiem szczególnym; domyślnie zawsze zalecałbym ich dodanie, ponieważ pomagają one przyspieszyć zarówno sprawdzanie integralności referencyjnej, jak i JOINograniczenia dotyczące FK. Ale nawet tutaj absolutnie słuszne jest „rozszerzenie” tych indeksów kolumn FK poprzez dodanie dodatkowych kolumn „włącz”, aby uczynić je jeszcze bardziej użytecznymi.

Możesz zobaczyć poprawę z indeksu zawierającego tylko 10 wierszy.

W poniższym teście na moim komputerze wersja bez indeksu została ukończona w 10.5ciągu kilku sekund, a wersja z indeksem w 9.8sekundach (spójna w ciągu 3 przebiegów).

Indeks w tym przypadku składa się tylko z 1 strony liścia, ale ponieważ tablica szczelin jest uporządkowana w kolejności według klucza indeksu, jego obecność pozwala SQL Serverowi po prostu zwrócić pojedynczy interesujący wiersz zamiast wykonywać agregację na wszystkich 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