SQL dynamique - EXEC (@SQL) ou EXEC SP_EXECUTESQL (@SQL)
Quels sont les avantages et les inconvénients de l’exécution d’une commande SQL dynamique dans une procédure stockée dans SQL Server en utilisant
EXEC (@SQL)
versus
EXEC SP_EXECUTESQL @SQL
?
sp_executesql est plus susceptible de promouvoir la réutilisation du plan de requête. Lorsque vous utilisez sp_executesql, les paramètres sont explicitement identifiés dans la signature appelante. Cet excellent article décrit ceci processus .
Erland Sommarskog doit obligatoirement lire: " La malédiction et les bénédictions de SQL dynamique " pour de nombreux aspects de SQL dynamique.
Le gros avantage de SP_EXECUTESQL est qu’il vous permet de créer des requêtes paramétrées, ce qui est très bien si vous vous souciez de l’injection SQL.
L'article de Microsoft sing sp_executesql recommande d'utiliser sp_executesql au lieu de l'instruction execute.
Étant donné que cette procédure stockée prend en charge la substitution de paramètres , sp_executesql est plus polyvalent que EXECUTE; et parce que sp_executesql génère des plans d'exécution susceptibles d'être réutilisés par SQL Server, sp_executesql est plus efficace que EXECUTE.
Donc, emporter: N'utilisez pas l'instruction execute. Utilisation sp_executesql.
Je voudrais toujours utiliser sp_executesql ces jours-ci, tout ce qu’il en fait est un wrapper pour EXEC qui gère les paramètres et les variables.
Cependant, n'oubliez pas OPTION RECOMPILE lorsque vous réglez des requêtes sur de très grandes bases de données, en particulier lorsque vos données couvrent plusieurs bases de données et que vous utilisez un CONSTRAINT pour limiter les analyses d'index.
Sauf si vous utilisez OPTION RECOMPILE, SQL Server tente de créer un plan d'exécution "taille unique" pour votre requête et exécute une analyse d'index complète à chaque exécution.
Ceci est beaucoup moins efficace qu'une recherche et signifie qu'il peut potentiellement analyser des index entiers qui sont contraints à des plages que vous n'interrogez même pas: @