Discussion :

[moumoune65]

Bonjour,
je travaille sur l'optimisation des requêtes sous SQL Server.
Pour comparer 2 requêtes, j'utilise le plan d'exécution réel de SQL Server Management Studio et notamment le champs Estimated Subtree Cost qui doit être le plus faible possible.

Voici les résultats obtenus pour l'exécution de 2 requêtes qui renvoient le même résultat :
- Requête 1 > Subtree cost : 0.25, temps d'exécution : plus de 5 secondes
- Requête 2 > Subtree cost : 0.52, temps d'exécution : moins de 1 seconde


Ma question est donc de savoir quelle requête est effectivement la plus efficace?
Est-ce que la requête 2 qui à un Subtree Cost faible n'aura pas un temps d'exécution beaucoup plus long sur une volumétrie plus importante?

Merci pour vos infos et vos pistes.

[darkelend]

bonjour,
pour pouvoir te répondre, il faudrait le ddl des tables et indexs (+ jeu d'essai) et les requêtes

[Donpi]

Je ne suis pas expert, mais j'ai envie de dire que dans "Estimated Subtree Cost", il y a "Estimated". Ce qui veux bien dire que la donnée est une estimation et par conséquent peu fiable...

[SQLpro]

Le cout estimé sera parfaitement fiable si :
1) la requête est purement ensembliste (donc aucun appel à des fonctions, même implicites)
2) les statistiques sont à jour.

A ces deux conditions, le cout estimé sera assez directement proportionnel au temps CPU (et non au temps d'exécution). En effet, passé un coût de 5 (paramétrable) l'optimiseur transforme le plan mono threadé en plan parallélisé (multi threadé) qui a la faculté de présenter en général un temps d'exécution moindre, mais un coût CPU comparable voir légèrement plus élevé.

A +

[moumoune65]

Merci pour vos réponses.
Dans ce cas, devons nous purement et simplement comparer les performances de 2 requêtes sur leur seule durée d'exécution?
Cette façon de faire me parait un peu simpliste. En effet, malgré un temps d'exécution plus rapide et un "Estimated Subtree Cost" (même peu fiable) élevé, ma requête n°2 ne risque-t-elle pas de devenir très lente lorsque je me trouverai dans une base avec un volume plus important de données?

[SQLpro]

Merci pour vos réponses.
Dans ce cas, devons nous purement et simplement comparer les performances de 2 requêtes sur leur seule durée d'exécution?

Certainement pas, mais bien sur leur cout estimé. La durée d'exécution dépend du contexte... En effet si le serveur est très occupé, la processus intégrera des temps de chargement/déchargement plus important que sur un serveur identique servant de test.

Cette façon de faire me parait un peu simpliste. En effet, malgré un temps d'exécution plus rapide et un "Estimated Subtree Cost" (même peu fiable) élevé, ma requête n°2 ne risque-t-elle pas de devenir très lente lorsque je me trouverai dans une base avec un volume plus important de données?

Pas non plus. En effet, l'optimiseur peut décider de changer de plan de requête en fonction de la volumétrie des données, comme de la distribution des données...

Par exemple dans cet article : http://blog.developpez.com/sqlpro/p9...alles_en_sql_1
on voir clairement que le plan change en fonction de l'augmentation de volume des données a manipuler...
Avec les requêtes 5 et 6 SQL Server passe de 297 (solution 5) ou 366 (solution 6) à 140 millisecondes alors que le volume des données augmente passant de 1000 à 3000...

A +

[moumoune65]

Merci pour ces remarques,
mais j'ai encore une question concernant l'utilisation des fonctions.
Ma requête 1, qui a un coût estimé faible, utilise des fonctions pour faire des jointures comme par exemple :

Code :

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

1
2
3
SELECT *
FROM MaTable1
JOIN MaTable2 on MaTable2.Id = fonctionBidon(MaTable1.Id

Est-ce que l'utilisation de telles fonctions dans une jointure est comprise dans l'estimation des coûts et est-ce une bonne idée (à mon avis pas vraiment)?
Enfin, l'utilisation de fonctions dans la partie Select (ex : Select uneFonctionDagregation()) qui va faire un requête d'agrégation (comme un select sum() sur d'autres tables) est-elle performante?

[elsuket]

Bonjour,

st-ce que l'utilisation de telles fonctions dans une jointure est comprise dans l'estimation des coûts et est-ce une bonne idée (à mon avis pas vraiment)?

Effectivement l'utilisation des fonctions scalaires et de table a plusieurs instructions ne permettant pas l'estimation des cardinalités, elles ne sont pas prises en compte dans l'estimation de coût. Seules les fonctions de table en ligne le sont.

l'utilisation de fonctions dans la partie Select (ex : Select uneFonctionDagregation()) qui va faire un requête d'agrégation (comme un select sum() sur d'autres tables) est-elle performante?

Oui, absolument. Encore faut-il qu'elles soient supportées par un index

@++

[aieeeuuuuu]

Bonjour,

Voici les résultats obtenus pour l'exécution de 2 requêtes qui renvoient le même résultat :
- Requête 1 > Subtree cost : 0.25, temps d'exécution : plus de 5 secondes
- Requête 2 > Subtree cost : 0.52, temps d'exécution : moins de 1 seconde

Si les deux requêtes renvoient le même résultat, on peut raisonnablement penser qu'elle manipulent les même données. Il se peut alors que la première mette plus de temps à s’exécuter car elle doit lire les données sur le disque, et que la deuxième est plus rapide simplement parce que les données sont déjà en cache...

vérifier les I/O de chaque requête peut être aussi un bon indicateur quant à leurs performances respectives.