Discussion :

[Sylvain James]

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 :

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

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

Requête 2 :

Code :

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

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

Sylvain

[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...

[Sylvain James]

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.

[iberserk]

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...)

[Sylvain James]

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.

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.

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

[SQLpro]

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 +

[iberserk]

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