Назад | Перейти на главную страницу

Секционированная таблица и параллелизм SQL Server 2008

Моя компания переходит на SQL Server 2008 R2. У нас есть таблица с тоннами архивных данных. Большинство запросов, использующих эту таблицу, используют значение DateTime в инструкции where. Например:

Запрос 1

SELECT COUNT(*) 
FROM TableA 
WHERE 
     CreatedDate > '1/5/2010' 
     and CreatedDate < '6/20/2010'

Я предполагаю, что разделы создаются на CreatedDate, и каждый раздел распределен по нескольким дискам, у нас 8 процессоров, а в базе данных 500 миллионов записей, которые равномерно распределены по датам с 01.01.2008. по 24.02.2011 (38 разделов). Эти данные также могут быть разделены на кварталы в год или другие периоды времени, но давайте оставим предположения до месяцев.

В этом случае я полагаю, что будут задействованы 8 процессоров, и только 6 разделов будут опрошены для дат между 05.01.2010 и 20.06.2010.

Что, если бы я выполнил следующий запрос и мои предположения остались бы такими же, как указано выше.

Запрос 2

SELECT COUNT(*) 
FROM TableA 
WHERE State = 'Colorado'

Вопросы?
1. Будут ли опрошены все разделы? да
2. Все ли 8 ЦП будут использоваться для выполнения запроса? да
3. Будет ли производительность лучше, чем запрос к таблице, которая не разделена на разделы? да
4. Что еще мне не хватает?
5. Как может помочь индекс раздела?

Я отвечаю на первые 3 вопроса выше, основываясь на моих ограниченных знаниях о секционированных таблицах и параллелизме SQL Server 2008. Но если мои ответы неверны, можете ли вы сообщить, почему я ошибаюсь.

Ресурс:

Обновление У нас есть кластерный индекс в БД и индексы покрытия по столбцам

BarDev

  1. да
  2. Возможно, в зависимости от того, какой индекс запрашивается и как этот индекс разделен.
  3. Возможно, опять же, в зависимости от того, какой индекс запрашивается и как этот индекс разделен.
  4. Для таблицы можно создать некластеризованный индекс, и этот индекс можно разделить по столбцу «Состояние», что будет очень быстро. Если есть индекс в другом столбце и включен столбец State, то сканирование этого индекса может быть дешевле для SQL Server.
  5. Наверное.