TOP et optimiseur

Bonjour,

Considérant une table incluant les champs suivants :

ID_DOC (int)

TITRE_DOC (varchar)

DTHR_DOC (datetime)

En réalité la table comporte de nombreux autres champs, mais inintéressants au regard de ma question (au passage elle est trop grosse, donc consomme beaucoup trop d' i/o, un dégraissage s'impose).

Admettons qu'un index cluster décroissant soit créé sur le champ DTHR_DOC.
Que la table fasse environ 300 000 lignes.

Je m'interroge sur la différences de performances quant aux 2 requêtes suivantes, dont les plans respectifs utilisent chacun l'index cluster.

Requête 1 :

Code:

---

1 2 3

SELECT * FROM matable WHERE predicats ORDER BY DTHR_DOC DESC // usage de l'index cluster

---

Requête 2 :

Code:

---

1 2 3

SELECT TOP 50 * FROM matable WHERE predicats ORDER BY DTHR_DOC DESC // usage de l'index cluster

---

La requête 2 montre des performances excellentes comparées à la requête 1.
Avec Management Studio cela peut se comprendre car la requête 1 doit ramener les 300 000 enregistrements.

Mais cela se confirme au sein d'une application qui procède pourtant en 2 étapes :
a) SQL Execute de la requête
b) Fetch record x 50

L'étape a) pourrait être aussi rapide pour les requêtes 1 et 2, car pour l'étape b) il suffirait à l'optimiseur de suivre l'index cluster dans l'ordre et d'isoler les enregistrements conformes aux prédicats du WHERE.

Visiblement, l'optimiseur, dans le cas de la requête 1, préfère parcourir tous les enregistrements, même si au bout du compte on ne "Fetch" qu'un seul enregistrement.

Vous allez me dire, c'est l'intérêt de la commande TOP.

Ce qui est ennuyeux, c'est qu'elle n'est pas standard, et pour ceux qui utiliseraient un ORM quelconque (je ne suis pas fan...), il est probable que la commande TOP ne sera pas utilisée, au profit d'un Execute classique suivi du nb de fetchs nécessaires.

Si vous avez des éléments complémentaires, ça m'intéresse :P

Sylvain

Bonjour,

Lorsque vous envoyez une requête depuis votre application, la requête est exécutée dans son intégralité, et le résultat est renvoyé au client. Ce que vous en faites ensuite dans votre application n'est plus du ressort du SGBD...

Citation:

---

Envoyé par aieeeuuuuu

Bonjour,

Lorsque vous envoyez une requête depuis votre application, la requête est exécutée dans son intégralité, et le résultat est renvoyé au client. Ce que vous en faites ensuite dans votre application n'est plus du ressort du SGBD...

---

Ce n'est pas très juste, le résultat n'est pas systématiquement renvoyé au client. Il faut que celui-ci le sollicite par ce qu'on appelle communément des "fetch record".
Ma question portait surtout sur le fait ou non que la requête soit exécutée en intégralité ou pas,
en me basant sur l'idée que dans certains cas de figure (notamment en présence d'index cluster sur lequel est posé un ORDER BY), un SELECT * pourrait être exécuté comme un SELECT TOP x *

Ce n'est pas le cas, mais ce n'est pas illogique.

En fait aieaieaie a raison:
La requête est exécutée dans son intégralité, mise en attente sur le réseau et consommée par votre DataReader (je suppose qu'il s'agit de lui...)
Ce n'est pas parce que vous vous ne parcourez que les 50 premiers que SQL SERVER n'a pas renvoyé toute les lignes...

Pour les ORM vous êtes dans le faux, ils sont justement là pour que vous ne vous posiez pas ce genre de question, chaque SGBD proposant sa propre implémentation du "TOP" l'ORM s'en servira (LINQ TO ENTITIES via take<50) génère un TOP 50...)

Citation:

---

Envoyé par iberserk

La requête est exécutée dans son intégralité, mise en attente sur le réseau et consommée par votre DataReader (je suppose qu'il s'agit de lui...)

---

En le formulant différemment je crois qu'on dit la même chose :)
Un résultat de requête "en attente sur le réseau", peut-être, mais où précisément sur le réseau ? Le serveur SQL stocke les résultats côté serveur, et les diffuse via le réseau, à la demande du client.
Dans mon cas, il ne s'agit pas d'un datareader (techno non microsoft) mais le principe de fonctionnement est le même.

Citation:

---

Ce n'est pas parce que vous vous ne parcourez que les 50 premiers que SQL SERVER n'a pas renvoyé toute les lignes...

---

Je suis d'accord sur le calcul du résultat, mais par contre, un serveur SQL ne renvoie pas systématiquement toutes les lignes.

Citation:

---

Pour les ORM vous êtes dans le faux, ils sont justement là pour que vous ne vous posiez pas ce genre de question, chaque SGBD proposant sa propre implémentation du "TOP" l'ORM s'en servira (LINQ TO ENTITIES via take<50) génère un TOP 50...)

---

Tant mieux alors, je pêche par pessimisme mais je te crois volontiers, effectivement c'est une bonne chose.
Il faut préciser que tu cites une configuration idéale : un ORM microsoft haut de gamme générant du SQL pour LE SGBD Microsoft.
Hibernate doit être dans le même cas de figure.
Il serait intéressant de voir ce que génèrent des ORM moins connus, ceux que l'on peut trouver dans les frameworks Zend, Play, et autres Django

Pour la pagination Hibernate est catastrophique. Il fait une requête générant toutes les lignes à chaque page pour ne renvoyer que le lot concerné....

A +

Mettez un profiler SQL et postez la requète générée...