Discussion :

[mikaeru]

Bonjour,
Je suis actuellement chargé d’optimiser la db d’une application qui a été très mal designer/optimisé, en gros le plaisir total pour un dba un peu maso.

Mon dilemme est que j’ai une table de plusieurs millions de rows avec +- 300 colonnes (et ce n’est pas le pire), qui subit des modifications assez fréquemment (insert/update) et je dois rajouter des indexes car les select deviennent problématique, j’ai « key lookup » à 73%.
La « where » clause est variable donc je n’ai pas toujours exactement la même querry.

Mon dilemme du moment est de choisir entre la peste et le cholera

La peste

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CREATE INDEX [idx_la_peste] 
ON [dbo].[T1] (c1,c2,c21,c20) 
INCLUDE (c10,c20,c24,c23,c86,c87)

La cholera

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CREATE INDEX [idx_le_cholera_1] 
ON [dbo].[T1] (c1,c2,c20) 
INCLUDE (c10,c20,c24,c23)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CREATE INDEX [idx_le_cholera_2] 
ON [dbo].[T1] (c1,c2,c21) 
INCLUDE (c10,c20,c86,c87)

A sachant que le include serait beaucoup plus large.

Selon vous quel serait le moins pire.

Merci d’avance.

[darkelend]

Tout dépend des types de chaque colonne, des requêtes, des stats d'exécution. Là comme ça, impossible à dire. Ce qui est sur, c'est qu'avec les indexs, tu vas gagner d'un coté pour perdre de l'autre. Tes indexs vont accélérer les lectures et potentiellement les mises à jour mais vont ralentir les insertions. Il faut trouver le bon compromis.

[aieeeuuuuu]

Mon dilemme du moment est de choisir entre la peste et le cholera

Dilemme cornélien !

La peste

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CREATE INDEX [idx_la_peste] 
ON [dbo].[T1] (c1,c2,c21,c20) 
INCLUDE (c10,c20,c24,c23,c86,c87)

La cholera

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CREATE INDEX [idx_le_cholera_1] 
ON [dbo].[T1] (c1,c2,c20) 
INCLUDE (c10,c20,c24,c23)

Dans ces deux index C20 n'a rien à faire dans les colonnes incluses puisqu'elle est déjà dans l'index.

Pour le reste, darkelend a tout dit.
Sans connaitre la structure de la table et les requêtes exécutées, impossible d'en dire plus.

[mikaeru]

Merci pour ta réponse
Le faite que j'indique le faite que je dois choisir entre le moins mauvais signifie que je connais un peu le poids d'un nouvel index
Comme précisé dans mon post initial c'est une table très active en lecture ET écriture donc idéalement je préférais créer un seul index mais étant donné que je ne suis pas encore un dieux en SQL (et j’ai encore du chemin), je souhaite l'avis de mes paires

Merci encore pour votre temps.

[aieeeuuuuu]

Comme déjà dit, il faut plus de détail.

quel type d’écriture ? insertion ou mise à jour ?

Cela n'a aucun sens de ne créer qu'un seul index pour "ne pas trop impacter vos performances".

Dire qu'un index est meilleur qu'un autre, n'a aucun sens en soit non plus. Un index peut être utile pour une requete, et totalement inutile pour une autre (même très semblable).

Il nous faudrait au moins avoir une idée de la structure et du contenu de votre table, les types de requêtes auxquelles elle prend part...

Vous semblez avoir un énorme problème de modélisation. Il serait certainement judicieux de commencer par revoir votre modèle.

Notez que dans ce contexte, vous pourriez envisager des index filtrés pour réduire l'impact négatif sur les éventuelles insertions.

[mikaeru]

Le double emploi du C20 est un typo ^^
Beaucoup d'insert /update/select

Les select sont en générale à 80% identique mais les 20% restant change selon les filtres que le user choisis.

Oui, le model est horrible et non on ne peut malheureusement pas le changer, donc je dois faire avec.

Les indexes filtré, c'est une option que j'avait completement oublié... mais je ne pense pas que cela sera très utile dans mon cas.