J'ai une requête qui est super rapide dans SQL Server Management Studio et super lente lorsqu'il est exécuté sous SP_EXecuteQL.
Est-ce à voir avec la mise en cache des plans d'exécution ne se produit pas lorsqu'il est exécuté sous SP_Executeql?
3 Réponses :
Non.
Vous pouvez voir les plans d'exécution et les comparer à l'aide de la requête suivante. P>
SELECT usecounts, cacheobjtype, objtype, text, query_plan, value as set_options
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
CROSS APPLY sys.dm_exec_query_plan(plan_handle)
cross APPLY sys.dm_exec_plan_attributes(plan_handle) AS epa
where text like '%Some unique string in your query%'
and attribute='set_options'
Pourquoi les plans d'exécution seront-ils si radicalement différents? Par exemple, j'ai examiné mon plan d'exécution de la requête directement à partir de SQL Management Studio (prend 3 secondes) et le plan d'exécution de SP_EXececuteSQL (prend plus de 5 minutes). Le plan de SP_EXECUTEQL ignore complètement quelques-uns des indices clés que l'appel direct trouvé. Quelqu'un peut-il expliquer pourquoi un appel de la direction Studio trouve des clés, mais l'appel via SP_Executesql ne le fait pas?
@Nathantregillus - Probablement le paramètre reniflant, vous pouvez regarder le plan Cached XML pour voir les valeurs des paramètres que le plan était en réalité compilé.
Merci pour la réponse @martinsmith. C'était en fait du fait que nous utilisons le contexteIfo comme filtre à notre avis et comment il n'est pas pris en compte dans le plan d'exécution
expérimenté le même comportement. (Définir les options égales) Requête régulière Production de plan parallèle et utilisant SP_EXececuteQL Il a produit un plan de série.
exec sp_executesql N'SELECT * FROM Theview WHERE departuretime BETWEEN @xyzParam1 AND @xyzParam2',N'@xyzParam1 datetime,@xyzParam2 datetime',@xyzParam1='Sep 1 2014 12:00:00:000AM',@xyzParam2='Sep 26 2014 11:59:59:000PM'
J'ai résolu une différence dans le plan de requête entre Ad-hoc TSQL dans SSMS et SP_EXECUTSQL en mettant à jour des statistiques. C'était une simple requête qui a touché la même table deux fois. Mettre à jour les statistiques déjà
Je me demande quand le mythe "sp_executesql ne met pas en cache" mythe mourra jamais - Lisez La malédiction et les bénédictions de dynamique SQL
@OMG Poneys - pourrait être un problème avec SP_EXecutesQL?
@JNK: Depuis l'expérience du comportement, j'ai mis en train de renifler anti-param par défaut de toute façon.
@Jnk - Il cache le plan et les réutilise donc oui.