SQL Performance Index

Question

Nous avons une table appelée 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) 

Il contient 10 millions de disques. Nous avons plusieurs procédures pointant vers « table1 » avec différents critères de recherche:

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

Quelle est la meilleure façon de créer un index non-cluster à part ci-dessus, ou de modifier les index existants pour obtenir une bonne performance de l'indice et de réduire le temps d'exécution ?

Answer 1

Et maintenant, pour répondre réellement ...

L'astuce ici est que vous avez une seule colonne lookups sur un certain nombre de colonnes, ainsi que des colonnes composites lookups. Vous devez comprendre avec quelle fréquence les requêtes ci-dessus s'exécutent - pour celles qui sont exécutées très rarement, vous devriez probablement les exclure de vos considérations d'indexation.

Vous pouvez mieux vaut créer des NCIX uniques sur chacune des colonnes interrogées. Ce serait probablement le cas si le nombre de lignes renvoyées est très petit, car les NCIX seraient capables de gérer les requêtes "single lookup" ainsi que les recherches composites. Alternativement, vous pouvez créer des NCIX à colonne unique en plus de couvrant des index composites - encore une fois, le facteur décisif étant la fréquence d'exécution et le nombre de résultats renvoyés.

Answer 2

C'est un peu dur de répondre avec juste l'information que vous avez fournie. Il y a d'autres facteurs que vous devez peser.

Par exemple: À quelle fréquence la table est-elle mise à jour et quelles colonnes sont fréquemment mises à jour? Vous devrez payer un coût pour ces mises à jour en raison de la maintenance de l'index.

Quelle est la cardinalité de vos différentes colonnes? Quelles requêtes exécutez-vous le plus souvent et quelles colonnes apparaissent dans la clause where de ces requêtes?

Vous devez d'abord déterminer quels sont vos paramètres de performance acceptable pour chacune de vos requêtes et travailler en tenant compte de ce que j'ai mentionné ci-dessus.

Avec 10 millions de lignes, le partitionnement de votre table peut être très logique ici.

Answer 3

Avez-vous pensé à utiliser le composant de recherche plein texte de MSSQL. Il pourrait offrir la performance que vous recherchez?