2009-05-28 4 views
1

У нас есть таблица под названием table1 ...SQL Performance Index

(c1 int indentity,c2 datetime not null,c3 varchar(50) not null, 
    c4 varchar(50) not null,c5 int not null,c6 int ,c7 int) 

on column c1 is primary key(clusterd Index) 
on column c2 is index_2(Nonclusterd) 
on column c3 is index_2(Nonclusterd) 
on column c4 is index_2(Nonclusterd) 
on column c5 is index_2(Nonclusterd) 

Он содержит 10 миллионов записей. У нас есть несколько процедур, указывающих на «table1» с различными критериями поиска:

select from table1 where c1=blah..and c2= blah.. and c3=blah.. 
select from table1 where c2=blah..and c3= blah.. and c4=blah.. 
select from table1 where c1=blah..and c3= blah.. and c5=blah.. 
select from table1 where c1=blah.. 
select from table1 where c2=blah.. 
select from table1 where c3=blah.. 
select from table1 where c4=blah.. 
select from table1 where c5=blah.. 

Что является лучшим способом для создания некластеризованного индекса, кроме выше, или модифицировать существующие индексы, чтобы получить хорошую производительность индекса и сократить время выполнения ?

+0

В ваших примерах запросов все предикаты являются проверками равенства столбца на одно значение. И несколько предикатов всегда сочетаются с оператором И. Я просто подтверждаю, что это так. То, что ваши запросы не используют предикаты LIKE, или операторы OR, или обматывают ссылки столбцов в функциях. – spencer7593

+0

Как насчет предложения select? Всегда одинаковое количество столбцов? – gbn

+0

То, как вы выразили свои индексы, немного сбивает с толку - вы говорите, что у вас есть два индекса (один кластер на c1, один не кластерный на c2, c3, c4, c5) или вы говорите, что у вас есть 5 отдельных индексы (одна кластеризована на c1, одна некластеризована на каждом из c2, c3, c4, c5)? –

ответ

6

А теперь на самом деле ответить ...

Хитрость здесь в том, что у вас есть Lookups одной колонки на любое количество столбцов, а также составных выборок столбцов. Вам нужно понять, с какой частотой выполняются вышеперечисленные запросы - для тех, которые выполняются очень редко, вы, вероятно, должны исключать их из соображений индексации.

может лучше создавать отдельные NCIX на каждом из столбцов, запрашиваемых. Вероятно, это будет так, если количество возвращаемых строк очень мало, так как NCIX сможет обрабатывать запросы «единого поиска», а также составные поисковые запросы. В качестве альтернативы вы можете создать с одним столбцом в дополнение к, охватывающим составные индексы - опять же решающим фактором является частота выполнения и количество возвращаемых результатов.

+2

Также имейте в виду, что если у вас есть индекс на (c1, c2), вам очень редко нужен он (c1). –

+0

, если частота для невидимых и комбинаций столбцов очень высока. Отдельные индексы являются точными или нам также необходимо создавать составные индексы, в соответствии с условиями поиска – rmdussa

+0

, что происходит с производительностью? если я создаю index_6 on (c1, c2, c3) и index_7 on (c2, c3, c4) и index_8 on (c1, c3, c5)? – rmdussa

0

Это довольно сложно ответить только с предоставленной вами информацией. Существуют и другие факторы, которые необходимо взвесить.

Например: Как часто обновляется таблица и какие столбцы обновляются часто? Вы будете платить за эти обновления за счет обслуживания индекса.

Какова мощность ваших разных колонок? Какие запросы вы выполняете чаще всего и какие столбцы отображаются в предложении where из этих запросов?

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

С 10 миллионами строк разбиение таблицы может иметь большой смысл здесь.

0

Вы подумали об использовании компонента полного текста MSSQL. Он может предложить производительность, которую вы ищете?