Я решил немного покопаться в этом вопросе и обнаружил некоторые интересные документы, рассказывающие о том, как и когда использовать, а может быть лучше, а не (форсировать) использование некластеризованного индекса.
Как следует из комментариев Джона Эйсбренера , одна из наиболее упоминаемых, даже в других блогах, это интересная статья Кимберли Л. Триппа:
но это не единственный, если вы заинтересованы, вы можете взглянуть на эти страницы:
Как видите, все они движутся вокруг концепции переломного момента .
Цитируется из статьи К.Л. Триппа
Какой переломный момент?
Это точка, в которой количество возвращаемых строк « недостаточно селективно ». SQL Server выбирает НЕ использовать некластеризованный индекс для поиска соответствующих строк данных и вместо этого выполняет сканирование таблицы.
Когда SQL Server использует некластеризованный индекс в куче, в основном он получает список указателей на страницы базовой таблицы. Затем он использует эти указатели для извлечения строк с помощью ряда операций, называемых Row ID Lookups (RID). Это означает, что, по крайней мере, он будет использовать столько же чтений страниц, сколько возвращенных строк, а возможно, и больше. Этот процесс несколько похож на кластерный индекс в качестве базовой таблицы, с тем же результатом: больше операций чтения.
Но когда наступит этот переломный момент?
Конечно, как и большинство вещей в этой жизни, это зависит ...
Не серьезно, это происходит между 25% и 33% от числа страниц в таблице, в зависимости от того, сколько строк на странице. Но есть и другие факторы, которые вы должны учитывать:
Цитируется из статьи ITPRoToday
Другие факторы, влияющие на переломный момент Хотя стоимость поисков RID является наиболее важным фактором, влияющим на переломный момент, существует ряд других факторов:
- Физический ввод-вывод намного эффективнее при сканировании кластерного индекса. Данные кластеризованного индекса последовательно размещаются на диске в порядке индекса. Следовательно, на диске очень мало бокового перемещения головки, что улучшает производительность ввода-вывода.
- Когда ядро базы данных сканирует кластерный индекс, оно знает, что существует высокая вероятность того, что следующие несколько страниц на дорожке диска будут по-прежнему содержать данные, которые ему необходимы. Таким образом, он начинает читать вперед в кусках по 64 КБ вместо обычных страниц по 8 КБ. Это также приводит к более быстрому вводу / выводу.
Теперь, если я выполню свои запросы снова, используя статистику ввода-вывода:
SET STATISTICS IO ON;
SELECT id, foo, bar, nki FROM my_table WHERE nki < 20000 ORDER BY nki ;
SET STATISTICS IO OFF;
Logical reads: 312
SET STATISTICS IO ON;
SELECT id, foo, bar, nki FROM my_table WITH(INDEX(IX_my_TABLE));
SET STATISTICS IO OFF;
Logical reads: 41293
Второй запрос требует больше логических чтений, чем первый.
Должен ли я избегать некластеризованного индекса?
Нет, кластерный индекс может быть полезен, но стоит потратить время и приложить дополнительные усилия для анализа того, чего вы пытаетесь достичь с его помощью.
Цитируется из статьи К.Л. Триппа
Итак, что нужно сделать? По-разному. Если вы хорошо знаете свои данные и проводите всестороннее тестирование, вы можете подумать об использовании подсказки (есть некоторые умные вещи, которые вы можете сделать программно в sps, я постараюсь посвятить этому пост в ближайшее время). Тем не менее, гораздо лучший выбор (если это вообще возможно) заключается в рассмотрении покрытия (это действительно моя главная мысль :). В моих запросах покрытие нереально, потому что мои запросы требуют все столбцы (зло SELECT *), но, если ваши запросы уже и они имеют высокий приоритет, вам лучше использовать индекс покрытия (во многих случаях) вместо подсказки, потому что индекс, который охватывает запрос, а не советы.
Это ответ на загадку на данный момент, но определенно есть куда больше погружаться. Переломный момент может быть очень хорошей вещью - и он обычно работает хорошо. Но, если вы обнаружите, что можете форсировать индекс и повысить производительность, вам может потребоваться провести расследование и посмотреть, действительно ли это так. Затем подумайте, насколько вероятна подсказка, и теперь вы знаете, на чем можно сосредоточиться.