Разделяйте часто и редко используемые данные кластерным индексом

Выбирая кластерный индекс, имейте в виду, что именно он определяет физический порядок записей таблицы на диске. Физический порядок определяет соседство записей на страницах, а те, в свою очередь, задают порядок загрузки и выгрузки страниц в память сервера. А это значит, что часто лучшим кластерным индексом будет такой, который разделяет часто и редко используемые записи. Давайте для примера рассмотрим таблицу заказов. Предположим, что у нас есть ClientID – идентификатор клиента и OrderDate – дата заказа. Пусть большая часть запросов содержит условие на ClientID как точное равенство и условие на OrderDate как диапазон. Рассмотрим ситуацию, в которой заказов в таблице очень много, но активно используется только заказы за последнюю неделю, и в запросе чаще всего указывается именно этот период. Классические рекомендации советуют выбрать индекс (ClientID, OrderDate). По первому полю будет происходить точное сравнение, по второму – сканирование диапазона. Так бы и стоило поступить, не будь этот индекс кластерным. Если вы сделаете такой кластерный индекс, то заказы за последнюю неделю будут разбросаны по всей базе данных! Загрузка их всех в память просто невозможна, и каждый запрос к данным нового клиента приведёт к физическому (а не логическому) чтению. Если же вы используете в качестве кластерного индекс (OrderDate), то, несмотря на ухудшение плана запроса, вы получите большой выигрыш на активно работающей базе данных. В самом деле при активной работе с заказами последней недели все страницы с данными большую часть времени будут находиться в памяти сервера. А сканирование диапазона дат в памяти, нужное для поиска данных по конкретному клиенту, как правило, быстрее, чем считывание с диска этих данных, даже по известному заранее адресу.

Не увлекайтесь созданием большого числа индексов

Обычно при тестировании индексированных запросов используют всевозможные выборки (т.е. запросы, выполняющие чтение данных). Это понятно – выборки не разрушают данные. Но при этом упускается очень важный момент – при вставке, удалении, а часто и при обновлении данных индексы работают противоположным образом. Нет, они, конечно, помогают найти строчки, нуждающиеся в изменении. Но потом тратится куча времени на реорганизацию изменённых данных, и в итоге порой получается гораздо медленнее, чем на базе данных совсем без индексов. Именно поэтому стратегия «добавим индексы везде, где что-то тормозит», глобально проигрывает при попытке хоть что-то изменить в этой базе данных. Более пяти индексов на большой таблице является почти приговором для процессов, которые как-то пытаются изменять индексированные поля.