Производительность индекса SQL

Question

У нас есть таблица с именем table1 ...

(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..

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

Answer 1

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

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

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

Answer 2

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

Answer 3

На этот вопрос сложно ответить только с помощью предоставленной вами информации. Есть и другие факторы, которые вам нужно взвесить.

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

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

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

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