Discussion :

[Estats]

Bonjour à tous,
je travaille sur l'optimisation en montée en charge d'un soft qui fait beaucoup de requetage sur une bdd DB2/linux 8.2.0 chargée avec une importante volumétrie.
Je voudrais votre avis sur l'organisation des index.
j'ai des requetes du type

Code :

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

1
2
3
4
5
SELECT * 
FROM T1 
WHERE T1C1=v1 
AND  T1C2=v2 
ORDER BY T1C1

Le where porte sur la clé primaire T1C1 et T1C2 mais dois-je aussi faire un index sur T1C2 seul ?
Inversement, j'ai des requetes du type

Code :

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

1
2
3
4
SELECT * 
FROM T1 
WHERE T1C1=v1 
ORDER BY T1C1, T1C2

où c'est le order by qui porte sur la clé primaire et le where sur un seul champ.

Que me conseilleriez-vous pour placer des index afin d'optimiser les performances ?

D'autre part, et comme j'entends tout et son contraire est-ce qu'un select * est plus consommateur (au niveau travail de DB2, je ne considère pas le trafic réseau) qu'un select de quelques champs (ca dépend certainement de la topologie de la table, mais dans un cas moyen) ?


En vous remerciant de vos conseils

[jab]

Tout d'abord oui un select * est plus lent. C'est simple à comprendre car plus de données sont lues et stockées en mémoire et éventuellement réécrites dans une table temporaire.

Pour les index, si j'ai bien compris ta clé primaire porte sur T1C1, T1C2. Dans ce cas, il n'y a pas d'optimisation possible du moins à ma connaissance.

[Luc Orient]

Code :

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

1
2
3
4
5
SELECT * 
FROM T1 
WHERE T1C1=v1 
AND  T1C2=v2 
ORDER BY T1C1

Si C1 et C2 forment la clé primaire, je ne vois pas comment on peut faire mieux comme accès ...
Par contre comme la requête va ramener une ligne (définition même de la clé primaire) pourquoi trier (une ligne !) sur C1 ?
Quelque chose doit m'échapper ...

Code :

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

1
2
3
4
SELECT * 
FROM T1 
WHERE T1C1=v1 
ORDER BY T1C1, T1C2

Là aussi difficile, à mon avis, de jouer sur les colonnes de l'index. Je ne vois pas ce qu'on peut faire !
Par contre la performance globale de la requête dépend de la sélectivité de la première colonne de l'index.

D'autre part, et comme j'entends tout et son contraire est-ce qu'un select * est plus consommateur (au niveau travail de DB2, je ne considère pas le trafic réseau) qu'un select de quelques champs (ca dépend certainement de la topologie de la table, mais dans un cas moyen) ?

A mon avis, du point de vue des performances, on a toujours interêt à citer dans une requête la ou les colonnes que l'on veut obtenir, surtout si il y a une différence significative avec le nombre total de colonnes de la table. La gain est-il important ? Là je ne sais pas trop ...

L'inconvénient du SELECT * est plus un problème de maintenance et d'évolutivité d'un logiciel par rapport au modèle physique des données surtout dans le cas d'un langage hôte.

[jab]

Par contre comme la requête va ramener une ligne (définition même de la clé primaire) pourquoi trier (une ligne !) sur C1 ?
Quelque chose doit m'échapper ...

Bien vu, cela m'avait échapé mais je pense que l'optimizer va se charger de ne rien faire .

[Estats]

Par contre comme la requête va ramener une ligne (définition même de la clé primaire) pourquoi trier (une ligne !) sur C1 ?
Quelque chose doit m'échapper ...

Bonsoir,
le order by vient du fait que les requêtes sont générées à partir d'un framework maison sous delphi et que ce framwork fait ses requêtes ainsi...
même s'il est évident que ca n'a pas toujours une grande utilité!

Merci de vos réponses
Estats