Discussion :

[Sergejack]

J'ai pu constater dans certains cas assez voire très rares et alors que l'on récupère des lignes qui sont toutes uniques, l'emploie de DISTINCT améliorait les performance (et ce de façon très importante).

Je n'ai pas d'explication (j'ai pourtant cherché) mais dans les changements que l'emploie de DISTINCT provoque dans le query plan, tant à l'exécution du plan qu'à son estimation (et c'est là que c'est fou*) il y a un gouffre de performance à l'avantage de l'emploie de DISTINCT.

Cela est tout à fait anormal mais c'est bon à savoir (surtout que vous ne lirez pas ceci partout) car puisque ne coûtant que 8 lettre, on peut se permettre d'expérimenté sur nos query les plus complexes (et peut-être avoir de plaisantes surprises).


* SQL Server établit plusieurs plans selon son IA et en retient le meilleur candidat.

[SQLpro]

Ce comportement est normal s'il existe un index couvrant par rapport à la clause SELECT.
Lisez les article que j'ai écrit à ce sujet et notamment "que faut-il indexer".

A +

[Sergejack]

Ce comportement est normal s'il existe un index couvrant par rapport à la clause SELECT.

Et en quoi "s'il existe un index couvrant par rapport à la clause SELECT", l'absence de DISTINCT résulte en une chute des performances ?

[mikedavem]

Je suis bien prêt à vous croire mais il faudrait pouvoir au moins avoir un exemple avec la requete et les plans d'exécutions ....

++

[iberserk]

Parlez vous de cas d'utilisation de distinct dans des sous-tables du SELECT comme ci-dessous?

Code :

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

1
2
3
4
5
 
FROM A INNER JOIN 
   (SELECT DISTINCT ... 
    FROM B) B
       ON B.ID=A.ID

Merci de poster votre exemple...
Je pense personnellement que les (le?) cas que vous avez rencontré montre un manque de statistique correct(ou manque de mise à jour de celles-ci) ou de contraintes manquantes empêchant SQL Server de correctement évaluer le nombre de ligne à traiter...