Самый главный совет – не следуйте советам

В том числе и этому, да. Все советы даются для частных случаев, которые могут никогда не сложиться в вашей базе данных. Проверяйте. Меняйте индексы, делайте запросы и следите за производительностью. Анализ планов запросов – это мощнейший инструмент, но даже он порой даёт сбои и неправильно оценивает стоимость различных вариантов выполнения. Самый надёжный вариант – это в QA щелкнуть правой кнопкой в окне редактирования, выбрать Current Connection Properties, а там – галочки Set statistics time и Set statistics IO. И затем уже выполнить тестовый запрос. Уверяю вас, если время компиляции и выполнения может зависеть от нагрузки сервера, число физических чтений определяется состоянием кэша страниц, то число логических чтений даёт почти идеальный параметр для оценки затрат на выполнение именно этого запроса. Ищите новые варианты, пробуйте их. Оптимизация индексов – это всегда очень интересно.

Управляем планами запросов

Эта задача немного проще предыдущей. Если нужный индекс на базе данных уже есть, но MS SQL Server им почему-то не пользуется, то довольно просто уговорить его это сделать. Стоп, не тянитесь писать with (index=<ИмяИндекса?>)! Это тоже вариант, но он нужен на крайний случай. Предлагаю вам свой список мер:

Выполните запрос dbcc freeproccache. Этот нехитрый запрос очищает кэш скомпилированных планов запроса и даёт серверу возможность перекомпилировать планы заново. Если сбой, нарушивший генерацию плана, был единичный, то новые алгоритмы окажутся правильными, и система оживёт. Но если вам приходится часто использовать dbcc freeproccache, то будьте внимательны – это может быть последствием какого-то неблагополучия сервера в целом.

Cгенерируйте дополнительную статистику. Вот уж чего, как говорится, много не бывает. Её можно «навешивать» хоть на каждое поле. Главное – не забывать регулярно выполнять перегенерацию (а лучше создать задание для регулярного выполнения таких действий).

Используйте подсказки для MS SQL Server, оставаясь в рамках стандарта ANSI-SQL. Предположим, что сервер выбрал использование индекса по полю, которое кажется вам наименее подходящим в такой ситуации. Всё просто – в секции запроса where пишите условие по этому полю не в виде прямого равенства или диапазона (например, Name = ‘Иван’), а с помощью функции COALESCE(<Имя поля>, <Имя поля>). Например, coalesce(Name, Name) = ‘Иван’. Это совершенно корректно математически, но при этом проблемный индекс по указанному полю не может быть использован. Другой пример – представьте, что у вас есть условие типа where @Number like Code + ‘%’. Если бы запрос был построен как Code like @Number + ‘%’, сервер сам догадался бы использовать индекс по Code. Но в нашем варианте Code используется в составе сложного выражения, и оптимизатор пасует. Человеку же очевидно, что @Number like Code + ‘%’ может быть верно только тогда, когда @Number >= Code, так как у них одинаковые первые символы, но @Number длиннее. Вот тут и имеет смысл добавить в условия @Number >= Code, так как оно не изменит логики и поможет серверу самостоятельно избрать нужный запрос.