Discussion :

[Matth_S]

Bonjour,

J'ai une table dans laquelle la clé est une combinaison de 3 id, il en resulte la création d'un index cluster sur cette clé primaire. Lorsque je requête cette table j'obtiens un comportement que je ne comprends pas :
un requête du type :

Code :

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

1
2
3
4
 
SELECT id1,id2
FROM ma_table
WHERE id1 IN (...) AND id2 IN (...) AND id3 IN (...)

sera très lente (voir plantera le serveur) avec ma clé primaire, par contre si je supprime la clé, la requête est instantanée.

J'ai passé la requête dans l'analyseur et j'obtiens le résultat suivant :
Avec la clé

clustered index seek
nombre de lignes 8
taille des lignes 15
cout estimé : 8

Sans la clé

table scan :
nombre de lignes 8
taille des lignes : 24
cout estimé : 3

En général un Index seek est plus rapide qu'un table scan ; je n'arrive pas à comprendre comment je peux obtenir l'inverse et surtout avec une telle différence.

J'ai résolu la lenteur en supprimant la clé, je vais recoder une partie de l'appli pour eviter les insertions multiples, par contre j'aimerai bien comprendre la cause pour éviter de reproduire la même erreur.

Merci !

[elsuket]

Bonjour,

Attention aux coûts, ils sont relatifs au temps total de requête.
Avez-vous comparé les temps de requête avec et sans index cluster ?
Pouvez-vous nous fournir le plan de requête dans les deux cas ?

A+

[SQLpro]

Vos IN multiples ne permettent pas d'activer une recherche sur l'index. Le prédicat n'est pas sargable.

A +

[Matth_S]

Merci pour vos réponses !

Attention aux coûts, ils sont relatifs au temps total de requête.
Avez-vous comparé les temps de requête avec et sans index cluster ?
Pouvez-vous nous fournir le plan de requête dans les deux cas ?

Le plan est très simple car il n'y a qu'une table de lue :
Sans index

Table scan : coût 100%
Filter : coût 0%
Select : coût 100%

Temps d'éxecution < 1s

Avec index

clustered index seek : coût 100%
Select : coût 0%

Temps d'éxecution = 2min13

Vos IN multiples ne permettent pas d'activer une recherche sur l'index. Le prédicat n'est pas sargable.

D'après ce que j'avais lu les index sur plusieurs colonnes sont stockés de manière concaténée ; comment aurais-je pu profiter d'un index sur plusieurs colonnes (avec une clause where du type (where id1=.. and id2=.. and id3=..) ? Comment ce fait-il que SQL Server n'ait pas choisi d'ignorer mon index puisque le prédicat n'est pas sargable ?

[SQLpro]

Parce que lire un index même en faisant un scan est souvent moins couteux que de lire une table entière... L'index est bien souvent plus petit que la table elle même...

A +