Discussion :

[imikado]

Bonjour,
VOici le problème rencontré aujourd'hui:

Soit la requête suivante:

Code sql :

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

SELECT top 1 monChamp,monchamp2 from maVue where maFK = 10 and maFK2 = 12 order by maPkey desc

Si on enlève le order by ou le top, la requête est quasi instantanée.

En cherchant un peu, on est tombé sur cet article:
http://www.mssqltips.com/sqlserverti...in-sql-server/

Et en modifiant ainsi la requête, elle devient instantannée :

Code sql :

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

1
2
3
DECLARE @i INT
SET @i=1
SELECT top(@i) monChamp,monchamp2 from maVue where maFK = 10 and maFK2 = 12 order by maPkey desc

Des commentaires ?, des astuces à partager sur le sujet ?

[SQLpro]

Le problème du TOP a été abordé maintes fois. Ce n'est pas une opération relationnelle et par conséquent ses performances dépendant grandement de paramètres physiques différents ainsi que de statistiques et d'indexation...

A +

[imikado]

Relisez mieux mon post:
Pourquoi

Code :

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

top(1)

Est plus lent que

Code :

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

top(@i)

(Avec @i égal à 1)

[aieeeuuuuu]

Bonjour,

Et en modifiant ainsi la requête, elle devient instantannée :

Code sql :

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

1
2
3
DECLARE @i INT
SET @i=1
SELECT top(@i) 1 monChamp,monchamp2 from maVue where maFK = 10 and maFK2 = 12 order by maPkey desc

Est-ce que le 1 après le TOP(@i) est une erreur de copier/coller ???
Sinon, ça peut expliquer la rapidité : la requête n'est plus la même, elle ne remonte plus le contenu de la colonne "monChamp", et peut éventuellement profiter d'un index couvrant, ou autre...

Avez-vous comparé les plans d’exécution des deux requêtes ?

[imikado]

Oui c'est une erreur de copier coller (j'ai corrigé dans le post d'origine)

L'idée c'est la différence entre le TOP 1 vs le TOP @i (avec @i égal à 1)

Non je n'ai pas regardé le plan d'éxécution, mais l'article cité est intéressant à lire

[elsuket]

Bonjour,

Ici je pense qu'il s'agit d'un petit problème d'estimation de cardinalités / reniflage de paramètres : il faudrait étudier le plan d'exécution pour s'en convaincre.

Lorsque le code est TOP 1, SQL Server réalise une estimation de cardinalité, et utilise en conséquence et par exemple, un index qui ne couvre pas la requête, et qui produit bien plus de key lookups qu'escompté, soit du fait d'une répartition inégale des cardinalités dans la plage de valeurs de maFK et maFK2.

En revanche en paramétrant la requête comme vous le faites avec une variable locale, on outrepasse l'estimation de cardinalités, ce qui fait que SQL Server utilise des règles d'estimation de cardinalités par défaut qui produisent un plan de requête plus efficace, par exemple qui utilise une index cluster qui couvre bien la requête.

Il serait intéressant de savoir également si vous avez un index sur les colonnes maFK et maFK2, si elles appartiennent à la même table, et si ledit index contient les colonnes monChamp et monChamp2. L'histogramme de la statistique sous-jacente sera également utile.

Il vous est donc nécessaire de collecter les deux plans réels d'exécution, et de les comparer pour voir où se situe la différence.
Une telle comparaison est facilitée par l'outil SQL Sentry Plan Explorer

[imikado]

Voila les 2 plans d'executions

[elsuket]

Merci. Malheureusement cela est insuffisant puisque les cardinalités ne sont pas exposées.

Le mieux est d'utiliser SQL Sentry Plan Explorer, qui comprend une fonctionnalité d'anonymisation de fichiers de plan d'exécution, et de mettre ces fichiers (pas les capture d'écran) en pièce attachée. Voici ce que l'on obtient par exemple :



@++