J'ai un morceau de SQL dynamique. Il faut environ 4 minutes pour courir. Si je prends plutôt la sortie du SQL et exécutez cela à la place, il faut environ 20 secondes. Pourquoi la divergence? Je sais que cela prendrait une certaine quantité de temps pour construire le SQL dans la version dynamique, mais je ne peux pas imaginer que ce soit aussi cher.
Quelqu'un a des idées? Les deux requêtes devraient être identiques, alors je soupçonnais que c'était quelque chose de bizarre avec la mise en cache du plan de requête, mais n'a pas vraiment beaucoup d'idée. P>
dans la dernière ligne SQL La dernière ligne est P> EXEC sp_executesql @myQuery,
N'@var1 INT,
@var2 INT,
@var2 INT',
@var1,
@var2,
@var3
4 Réponses :
Je vais supposer que vous utilisez Microsoft SQL Server (vous avez uniquement marqué votre question "SQL").
Il existe certains cas où différentes valeurs de paramètres peuvent entraîner un plan d'optimisation différent. Ensuite, ce plan d'optimisation est mis en cache et utilisé la prochaine fois que vous exécutez la requête avec différentes valeurs de paramètres. Mais le plan d'optimisation n'est pas le meilleur plan pour les valeurs de paramètre suivantes.
Voici un article sur ce problème et quelques solutions de contournement: https://www.simple-Talk.com/sql / programmation T-SQL / paramètre-renifler /
Donc, oui - il y a des cas où l'utilisation d'une requête paramétrée peut entraîner des performances médiocres par rapport à l'exécution de la même requête sans paramétrage.
Nous ne pouvons pas savoir si cela s'applique dans votre cas si vous n'êtes pas à la liberté de publier votre code.
Je respecte que vous ne pouvez pas faire cela - en publiant sur Stackoverflow, Vous autorise implicitement votre code et / ou des mots avec une licence Creative Commons . Mais il ne serait pas approprié de partager du code appartenant à votre employeur, à moins qu'ils ne soient acceptés.
OP a le problème opposé; La requête sans paramétrage fonctionne beaucoup plus lentement que la requête avec le paramétrage.
@PieterGeerkens, ce n'est pas la façon dont je lis le problème décrit de l'OP.
Parmi les paramètres de la manière, VS ne peut pas causer différents plans de requête. Et différents plans de requête entraîneront des temps d'exécution différents.
Comme le dit Bill Karwin, cela pourrait être un problème «paramètre reniflant». Essayez d'inclure la ligne: à la fin de votre requête SQL. Il existe un article ici expliquant ici quel paramètre renifler est: http://blogs.technet.com/b/mdegre/archive /2012/03/19/what-is-parameter-sniffing.aspx
Si vous utilisez SQL Server 2008 ou version ultérieure, utilisez l'optimisation pour un indice de requête inconnu. Ajoutez les éléments suivants à la fin de votre requête dynamique:
OPTION (OPTIMIZE FOR (@var1 UNKNOWN, @var2 UNKNOWN, @var3 UNKNOWN))
Merci. J'allais donner la prime à Ninjapixel au départ, mais cette réponse est encore meilleure.
Heureux d'avoir pu aider
Ajoutez un commentaire à votre requête dynamique. Mettre dans les valeurs de commentaire des variables @ var1, @ var2, @ var3 etc.
On ressemblera à: P>
EXEC sp_executesql @myQuery,
/* var1Value, var2Value, var3Value */
N'@var1 INT,
@var2 INT,
@var2 INT',
@var1,
@var2,
@var3
S'il vous plaît poster votre code.
Pouvez-vous montrer votre code?
Vous devriez ajouter de la place plus d'informations, mais si le code papier est beaucoup plus rapide, alors vous faites certainement quelque chose de mal.
Malheureusement je ne peux pas. C'est une énoncé de SQL dynamique massive que je ne peux pas partager et prendrait beaucoup de temps à obscurcir en raison de la taille.
Lorsque vous dites que vous «prenez la sortie du SQL et courez cela à la place», qu'est-ce que vous voulez dire exactement? Prenez-vous la dernière instruction SQL qui est exécutée sur le serveur DB?
Vous faites certainement quelque chose de mal. J'utilise systématiquement SQL dynamique pour améliorer les performances, par des valeurs de codage rigide qui seraient autrement des paramètres. Je n'ai jamais eu de performance dégrader, même un peu, de le faire.
WillOEM: Dans la version dynamique, la dernière ligne est EXEC SP_EXECUTSQL '@MYQUERY, ... (paramètres). J'ai pris la valeur de MyQuery et j'ai couru à la place.
@ user1652427 - Si vous attendez de l'aide, vous devez commencer à réduire votre requête au point où il peut être partagé mais présente toujours le comportement que vous décrivez. Il est très probable que vous utilisez vous progressez le long de ce processus que vous pouvez résoudre le problème vous-même.
@Shadow pourquoi la prime? Cette question n'a pas suffisamment d'informations pour obtenir une réponse significative. En fait, je suis surpris que ce n'était pas fermé. Si vous avez un problème similaire, ce serait peut-être dans le meilleur intérêt de chacun si vous pouvez poster une meilleure question. Le problème réside dans tout ce qui se passe à l'intérieur
@myquery ... quelque chose que nous ne pouvons pas deviner.@CRAGYOUNG parce que j'ai eu le même problème et que l'une des réponses a résolu ce problème. J'ai encore une autre réponse, je dois toujours tester, mais l'un d'entre eux obtiendra la prime. Ce problème spécifique ne peut pas vraiment être décrit beaucoup mieux: l'utilisation de "sp_executesql" prend beaucoup plus de temps que d'exécuter le même SQL directement, par ex. via SSMS. Il n'y a aucun code à partager, non "Qu'avez-vous fait" pour partager - un problème ennuyeux qui est répondu ici. Pourrait ne pas adapter le débordement de la pile, mais c'est utile. Période.
@Shadowwizard Je suppose que vous n'avez pas d'informations sur le problème sous-jacent? Par exemple. La première manche de DSQL est rapide, mais d'autres non. Ou répéter la course avec les mêmes paramètres est bien. Ou comment les paramètres peuvent différer / affecter des choses? La chose est que je pense Cette question pourrait être très intéressante et utile si cela avait quelque chose de concret à travailler. - J'aimerais presque offrir une prime pour trouver une meilleure question. : P
@CRAGYOUNG Eh bien, je pense Je comprends ce que vous voulez dire. Je peux, en théorie, modifier la question pour refléter mon problème spécifique et donner plus de codes plus / meilleur, mais ce serait toujours quelque chose qui ne peut pas vraiment être reproduit, autant que je sache.