У який момент показник стає ефективним

Я знайшов чимало ресурсів, де згадується, що додавання індексу до таблиці робить пошук швидшим і вставляє повільніше, але тільки якщо таблиця велика. Це створює компроміс, який є дизайнерським рішенням, але має бути приблизний розмір таблиці, перед яким використання індексу є абсурдним. (10 рядків, наприклад, мабуть, нижче цієї межі)

Хтось знає про те, де би знаходився цей ліміт, чи знає про ресурс, який би вказував мені в правильному напрямку?

Точний ліміт насправді важко визначити достроково.

Одне, що більшість людей недооцінюють, - це високі вимоги, які повинен виконувати індекс, перш ніж він стане кандидатом для використання у запиті.

Ефективний (некластеризований) індекс

• пропонує велику вибірковість , наприклад, повертає лише дуже невеликий відсоток (<1%, <2%) від загальної кількості рядків. Якщо вибірковість не задана - оптимізатор запитів SQL Server, швидше за все, ігнорує цей індекс

• в ідеалі має охоплювати запит, тобто повертати всі стовпці, необхідні для запиту. Якщо ви можете створити індекс, що містить 1 або 2 стовпчики індексу, і включає ще декілька (2-4) стовпців як включені стовпці, і таким чином ви можете охопити запит - тоді ймовірність оптимізатора запитів буде використовувати цей індекс. Що також означає: якщо ваш код завжди використовується SELECT * .....для отримання всіх стовпців , ймовірність використання індексів знижується - досить кардинально, насправді

Я впевнений, що існує також ряд інших критеріїв - але я вважаю, що ці два є найважливішими. Звичайно, ви завжди повинні підтримувати свої індекси належним чином (реорганізовувати, перебудовувати) та стежити за тим, щоб статистика, пов’язана з вашими індексами, була актуальною.

PS: некластеризовані індекси стовпців із зовнішніми ключами є окремим випадком; за замовчуванням я завжди рекомендую додавати їх, оскільки вони допомагають пришвидшити як референтну перевірку цілісності, так і JOIN'ті обмеження ФК. Але навіть тут абсолютно "розширити" ці індекси стовпців FK, додавши додаткові колонки "включити", щоб зробити їх ще кориснішими.

Можливо, ви побачите покращення від індексу лише з 10 рядками.

У наступному тесті на моїй машині версія без індексу завершена за 10.5секунди, а версія з індексом у 9.8секундах (послідовно протягом 3 циклів).

Індекс у цьому випадку складається лише з 1 аркушної сторінки, але оскільки масив слотів упорядкований у порядку індексних ключів, його наявність дозволяє SQL Server просто повертати один рядок, що цікавить, а не виконувати агрегацію на всіх 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