ссылка Дункана содержит хороший набор советов. Вот еще несколько советов:
Если вам не нужно запрашивать полностью обновленные данные (т. Е. Допустимы ли данные до последнего часа или закрытия рабочего дня вчера), рассмотрите возможность создания отдельного витрина данных для аналитики. Это позволяет оптимизировать это для быстрых аналитических запросов.
В оптимизаторе запросов SQL Server есть оператор преобразования "звезда". Если оптимизатор запросов повторно определяет этот тип запроса, он может выбрать нужный фрагмент данных путем фильтрации на основе таблиц измерений, прежде чем он коснется таблицы фактов. Это уменьшает количество операций ввода-вывода, необходимых для запроса.
Для приложений VLDB, включающих сканирование больших таблиц, рассмотрите возможность хранения с прямым подключением с использованием как можно большего количества контроллеров, а не SAN. Вы можете получить большую пропускную способность дешевле. Однако, если ваш набор данных меньше (скажем) 1 ТБ или около того, это, вероятно, не будет иметь большого значения.
64-битный сервер с большим количеством оперативной памяти подходит для кэширования, если в ваших запросах используется локальная ссылка. Однако сканирование таблицы не имеет ссылочного местоположения, поэтому, когда оно становится значительно больше, чем ОЗУ на вашем сервере, дополнительная память больше не помогает.
Если вы разбиваете свои таблицы фактов, рассмотрите возможность размещения каждого раздела в отдельном дисковом массиве или, по крайней мере, в отдельном канале SAS или SCSI, если у вас есть массивы SAS с репликацией портов. Обратите внимание, что это будет иметь значение только в том случае, если вы регулярно выполняете запросы между несколькими разделами.