В какой момент наличие индекса становится эффективным

Я нашел много ресурсов, в которых упоминается, что добавление индекса в таблицу делает поиск быстрее и вставляет медленнее, но только если таблица большая. Это создает компромисс, который является дизайнерским решением, но должен быть приблизительный размер таблицы, перед которым использование индекса абсурдно. (10 строк, например, вероятно, ниже этого предела)

Кто-нибудь знает о том, где будет этот предел, или знает о ресурсе, который укажет мне правильное направление?

Точный предел действительно сложно определить заранее.

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

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

• предлагает большую избирательность , например, возвращает только очень маленький процент (<1%, <2%) от общего числа строк. Если избирательность не задана - оптимизатор запросов SQL Server, скорее всего, будет игнорировать этот индекс

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

Я уверен, что есть и множество других критериев, но я считаю, что эти два являются наиболее важными. Конечно, вы всегда должны поддерживать свои индексы должным образом (реорганизовывать, перестраивать) и следить за тем, чтобы статистика, связанная с вашими индексами, была актуальной.

PS: некластеризованные индексы на столбцах внешнего ключа являются особым случаем; по умолчанию я всегда рекомендовал бы добавлять их, поскольку они помогают ускорить как проверку ссылочной целостности, так и проверку JOINэтих ограничений FK. Но даже здесь абсолютно справедливо «расширять» эти индексы столбцов FK, добавляя некоторые дополнительные столбцы «include», чтобы сделать их еще более полезными.

Вы можете увидеть улучшение по сравнению с индексом только с 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