Причина, по которой вы используете столбцы в некластеризованном индексе, заключается в том, чтобы избежать «поиска по закладкам» в кластеризованных данных. Дело в том, что если SQL Server теоретически может использовать определенный некластеризованный индекс, но, по оценкам Оптимизатора, будет слишком много просмотров закладок, тогда этот индекс будет игнорироваться. Однако, если все выбранные столбцы доступны непосредственно из индекса, нет необходимости в поиске закладок.
В вашем случае тот факт, что вы получаете доступ к данным через «поиск по кластеризованному индексу», очень многообещающий. Будет очень трудно улучшить его производительность. Некластеризованный индекс, включающий все выбранные столбцы, может быть немного быстрее, но только потому, что необработанные данные немного меньше. ( Но не забывайте о стоимости увеличенного времени вставки / обновления .)
Тем не менее, вы должны проверить детали ...
- Если вы используете составной ключ, а поиск происходит только в начале ключа, вам может не повезти. Вы можете обнаружить, что поиск только сужается до 500 000 строк, а затем выполняет поиск по другим критериям. В этом случае поэкспериментируйте с некоторыми некластеризованными индексами.
- Кластерный индекс сам по себе может быть в порядке; но если это делается 100 000 раз в вашем запросе, потому что какой-то другой аспект неэффективно возвращает слишком много строк - тогда вы не получите много, улучшив производительность поиска по кластерному индексу.
Наконец, уточните комментарий Давека: «стоимость относительна». То, что кластеризация составляет 77% от стоимости вашего запроса, не означает, что есть проблема. Можно написать тривиальный запрос к 1 таблице, который возвращает строку извлечения и стоимость поиска в кластеризованном индексе на уровне 100%. (Но, конечно, будучи единственной «проделанной работой», это будет составлять 100% работы ... и 100% мгновенного использования по-прежнему мгновенного .
Итак: «Не волнуйся, будь счастлив!»