Discussion :

[KyoshiroKensei]

Bonjour,

J'ai eu un problème sur une procédure stockée. Elle mettait 23 seconde à s'exécuter. Après recherche, il s’avère qu'un select prend 22 secondes d’exécution. Le plan d’exécution me semble curieux (2 boucle imbriquée?)

Après plusieurs tests, je constate les faits suivant:
- l'instruction posant problème s’exécute en moins de 1 seconde hors procédure stockée
- en supprimant le tri selon la colonne, l’exécution est immédiate.

Dans l'image est présente la requête 1 qui pose problème.

J'ai solutionné le problème en mettant le résultat (sans le top 1) de la requête 2 dans une table temporaire, puis en faisant un top 1 + order by sur cette table temporaire.

Du coup, je m'interroge sur l'utilisation de la clause order by. J'ai l'impression que l'order by ne s'applique pas uniquement à mon jeux de résultat. Je souhaiterai avoir vos avis.

La table lue contient 3 millions de lignes, les index non fragmentés. La requete retourne 600 lignes.

[aieeeuuuuu]

Bonjour,

Il faudrait connaitre les index qui existent sur vos tables. Vos statistiques sont-elles à jour ?

Visiblement, SQL server change de stratégie avec le ORDER BY afin de profiter d'un troisième index.

Vous pouvez essayer les fonctions analytiques :

Code :

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

1
2
3
4
5
6
7
8
9
 
WITH CTE AS (
     SELECT idTbarre
        ,ROW_NUMBER() OVER(ORDER BY DateHeure) AS RN
        FROM  ... --la suite de votre requete
)
SELECT idtBarre 
FROM CTE
WHERE RN = 1

[KyoshiroKensei]

Je pense que les statistiques étaient à jour, le plan de maintenance mettant à jour les statistique datant de moins de 5 heures. Il a les index non cluster suivant:


Action + Position
IdtBarre Desc
Position
Position + Dateheure Desc
Position + Idtbarre Desc

[hmira]

C'est connu, la clause Order By influence à coup sûr la stratégie de l'optimiseur dans l'élaboration du plan optimal. Un index qui va dans le même sens que l'ordre by sera "préviligié" ou du moins "retenu" par l'optimiseur. Dans ce contexte, l'optimiseur s'affranchit de l'opération Trier (Sort) puisque les lignes sont déjà triées au travers l'index au moment de leur extraction.

Dans l'exemple de la première requête l'order by (ORDER DateHeure ASC) plus le filtre Sui.Position = 'PFC1' , fini par coïncider avec l'index TabSuiviBarre.Position_DateHeure.. (qui je crois est établi sur Position+Dateheure à confirmer par KyoshiroKensei ). Et, c'est la raison pour laquelle, on ne voit pas l'opération Trier (Sort) dans le premier plan alors qu'il y a bien un "ORDER BY DateHeure ASC"

A partir de SQL Server 2008 R2, vous pouvez utiliser les Hint pour le cas échéant forcer l'utilisation d'index. Dans votre cas, ce sera forcer l'utilisation de l'index Position_IdBarre (au lieu de l'index Position_DateHeure utilisé actuellement par l' optimiseur dans la première requête). Il faut faire le test et mesurer les perf. parce si vous forcer l'utilisation de l'index Position_IdBarre, tout en gardant l'Order by (ORDER BY DateHeure ASC), vous allez voir une Opération Trier (Sort) qui va apparaître en plus dans le plan, espérant que celle-ci ne va pas à nouveau "plomber" votre plan d'exécution.

Pour cela, vous pouvez utiliser le hint FORCESEEK comme indiqué ci-dessous :

Code SQL :

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

1
2
3
4
..... 
FROM  dbo.TabSuiviBarre sui  WITH (FORCESEEK(Position_IdtBarre(Position) ))
.... 
ORDER DateHeure ASC

A+

PS : Tout cela est pour vous proposer des solutions de contournement, mais ne répond évidemment pas à la question : "Pourquoi, dans la requête n° 1, l'optimiseur a été fourvoyé en élaborant un plan qui est loin d'être le plus optimal !

A+

[KyoshiroKensei]

bonjour,

je confirme pour l'index.

Merci de votre réponse, je vais tester en forçant l'utilisation de l'index pour voir l'impact sur les performances. D'habitude, j'étais plutôt contre l'utilisation de table temporaire, mais maintenant que je vois cela, je vais être plus prudent dans l'utilisation des ORDER By.

[aieeeuuuuu]

Position
Position + Dateheure Desc

Le deuxième est redondant avec le premier.
Je pense que la première chose à faire est de revoir votre stratégie d'indexation...