Discussion :

[olivierN]

Bonjour,

J'ai actuellement une requête du type

select champ1, champ2, champ3
from tdetail
where idmaitre=:idmaitre
group by iddetail

j'utilise cette requête dans une boucle, et le group by dégrade fortement les performances c'est à dire moins de 1ms sans et 30ms avec. Est-ce normal, et est-ce que je peux faire quelquechose?

--

[Barbibulle]

J'imagine que ce que tu appels Champ1, Champ2, et Champ3 c'est IDDetail oubien des fonctions d'aggrega. Sinon cette requette n'a pas de sens.

A ce sujet : ca veux dire que iddetail de la table tdetail ce n'est pas la clé primaire et donc tu as des doublons ?

Si tu réponds à oui à ces deux questions, je te répond que oui c'est normal qu'un group by déteriore les performances car c'est en fait un tri suivie de traitements d'aggregas. Ceci dit il faut s'assurer que iddetail est soit indexé soit est un clé primaire ou étrangère. Sinon les performances seront catastrophiques (si la table contient beaucoup de lignes)

Sinon (tu as répondu non à une des deux questions) c'est que ta requete n'as pas de sens....

[olivierN]

Non j'ai été un peu vite en tapant ma requête, c'est un order by et non group by . En fait je veux récupérer mes données dans l'ordre d'insertion qui est l'ordre de le clé primaire de la table. Et c'est pour cette raison que je ne comprends pas bien la baisse de perf.
Pour un enregistrement maitre, il ne me reste plus qu'une dizaine d'enregistrements détail, alors à ce moment là un order by sur la clé ne devrait pas changer grand chose.
De plus, plus le nombre d'enregistrement dans la table est grand plus les perf se dégradent.
J'espère quand même que le tri sur les enregistrement est fait après avoir filtrer les enregistrements par la clause where!

[Barbibulle]

1-Quel est la structure de la table et les index/clé primaires/clés étrangères ?
Et le nombre de ligne de la table et le nombre le ligne (en moyenne) pour un IDMaitre ?

2- Les deux tests onts été fait dans les mêmes conditions ? (premier ordre select sur le serveur suite à l'allumage) ou l'un apres l'autre ?

[WOLO Laurent]

Ajoute un index sur le champ idDetails pour accelerer les recherches.

[olivierN]

C'est assez simple
une clé primaire iddetail
une clé étrangère idmaitre
un index sur la clé étrangère
en moyenne 20 enregistrements détails pour un enregistrement maitre

Les tests ont été fait avec ibadmin l'un a la suite de l'autre et plusieurs fois en alternant une fois avec, une fois sans order by en ainsi de suite et a chaque fois en lançant la requête au moins une dizaine de fois.

Et dans ces condition ibadmin me donne 0ms pour l'une et 30ms pour l'autre.

[olivierN]

Réponse à WOLO Laurent

Est-ce mettre un index sur la clé primaire apporte quelquechose?

[WOLO Laurent]

Réponse à WOLO Laurent

Est-ce mettre un index sur la clé primaire apporte quelquechose?

Justement c'est pour cela que nous conseillons de poster également le script de création de tous les objets évoqués dans le sujet.

Je ne pouvais pas imaginer des clés primaires sur tel champs et des clés etrangères dans d'autres.

Généralement, un index est créé pour chaque clé primaire ou étrangère, je ne voie donc plus d'interêt de l'ajouter sauf si c'est spécifique pour ce SGBDR.

Entre temps, on vous a demandé le nombre d'enregistrement...

[Barbibulle]

Normalement le fait de créer une clé etrangère suffit, (il crée automatiquement un index)

Par contre tu ne nous a pas dit combien de ligne il y a dans la table.

A mon avis pour résoudre ton problème je vois deux solutions :

La première (la plus simple) :
Fait un :

Code :

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

1
2
3
4
select champ1, champ2, champ3 
from tdetail 
where idmaitre=:idmaitre 
order by idmaitre, iddetail

Et oh magie il utilise le même plan que celui sans le order by (sinon il utilise le plan de la clé primaire ce qui explique la baisse de performance)

Deuxième solution
il suffit de lui forcer le plan.
1- Execute la requete

Code :

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

1
2
3
select champ1, champ2, champ3 
from tdetail 
where idmaitre=:idmaitre

sous IBconsole, dans l'onglet PLAN (en bas a coté du résultat) tu dois avoir un truc du style :
PLAN (DETAIL INDEX (RDB$FOREIGNXX)) ou XX est un numéro.

2- Execute enfin la requete suivante :

Code :

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

1
2
3
4
5
select champ1, champ2, champ3 
from tdetail 
where idmaitre=:idmaitre 
PLAN (DETAIL INDEX (RDB$FOREIGNXX))
order by iddetail

Et encore un miracle aux mêmes effets bénéfiques...

[olivierN]

Merci a tous les deux pour vos réponse, et désolé de mon manque de précision.

La solution (simple) fonctionne éffectivement très bien. Même si j'aimerais bien comprendre plus en détails pourquoi!

[Barbibulle]

Et bien lorsqu'on soumet une requete à un SGBD, celui ci doit choisir (le plus rapidement possible) la stratégie d'accés aux données. Ce n'est qu'une stratégie qui est basé sur des statistiques de selectivité des index, et les principês assez simple de raisonnement.

Certains SGBD tres paramétrables (mais du coup qui necessite un DBA à domicile) permettent d'influer sur les statégies d'accées aux données pour optimiser celle-ci.

Dans le cas présent apres analyse de la requete il choisit (il fait le pari) que l'utilisation de la clé primaire pour le ORDER BY sera plus rapide pour trier les données (Ce qui serait certainement vrai s'il y avait beaucoup plus de lignes sélectionnées) Donc il préfère utiliser l'index de la clé primaire pour le tri.

Or dans le cas présent il perd son pari car il n'y a aps assez de données dans la table pour que ca soit rentable.

Les solutions que j'ai donné consiste à influencer le SGBD pour qu'il prenne la bonne décision (qui sera peut etre fausse dans vous aurez plus de volume de données : et c'est aussi le role d'un DBA que d'ajuster les requetes et stratégies en fonction de l'évolution des volumes des données).

Donc en lui présisant le plan on le force à adopter une stratégie et en lui indiquant order by idmaitre, iddetail on l'influence également car pour ce tri il va chercher l'index le mieux adapté et cette fois c'est l'index de la clé étrangère....

Voilà.