EXEC vs SP_EXECUTESQL Performance
Récemment, nous avons utilisé un outil de révision de code SQL contre notre base de données. Il suggère d'utiliser SP_EXECUTESQL au lieu de EXEC.
Je connais SP_EXECUTESQL nous aide à éviter l'injection sql. Y a-t-il une différence de performances lors de l'utilisation de EXEC vs SP_EXECUTESQL.
Il s'agit principalement d'une préférence en raison de la sécurité et de la cohérence, et n'a rien à voir avec les performances (bien que cela ait pu être plus un problème dans les anciennes versions de SQL Server).
Pourquoi utiliser EXEC() parfois lorsque vous devriez utiliser sp_executesql Chaque fois que vous avez des paramètres? EXEC() vous oblige à concaténer toutes vos variables en une seule chaîne, ce qui la rend mûre pour les abus.
J'ai écrit à ce sujet plus en détail ici:
J'ai également écrit sur la protection contre l'injection SQL ici:
- Se protéger de l'injection SQL dans SQL Server - Partie 1
- Se protéger de l'injection SQL dans SQL Server - Partie 2
L'injection SQL est un gros problème, et de nombreuses autres personnes ont également écrit à ce sujet.
Enfin, assurez-vous que lorsque vous appelez des procédures système, vous utilisez le boîtier approprié pour faire correspondre ce qui est stocké dans sys.all_objects - ce doit être en minuscules. Sinon, si votre code est déployé sur une instance sensible à la casse, tout commencera à échouer.
Tout d'abord, vérifions la signification des deux commandes:sp_executesql: Exécute une instruction ou un lot Transact-SQL qui peut être réutilisé plusieurs fois ou qui a été créé dynamiquement. L'instruction ou le lot Transact-SQL peut contenir des paramètres incorporés.exec: exécute une chaîne de commande ou une chaîne de caractères dans un lot Transact-SQL, ou l'un des modules suivants: procédure stockée système, procédure stockée définie par l'utilisateur, CLR (Common Language Runtime) stocké , une fonction définie par l'utilisateur à valeur scalaire ou une procédure stockée étendue. L'instruction EXECUTE peut être utilisée pour envoyer des commandes directes aux serveurs liés.
quelques-unes des principales références:
sp_executesqlPermet de paramétrer les instructions, c'est donc plus sûr qu'EXEC en termes d'injection SQLsp_executesqlPeut tirer parti des plans de requête mis en cache. La chaîne TSQL est générée une seule fois, après chaque fois qu'une même requête est appelée avecsp_executesql, SQL Server récupère le plan de requête du cache et le réutilise.- Les tables temporaires créées dans EXEC ne peuvent pas utiliser le mécanisme de mise en cache des tables temporaires.
Références:
https://blogs.msdn.Microsoft.com/turgays/2013/09/17/exec-vs-sp_executesql/
https://msdn.Microsoft.com/en-us/library/ms188001.aspx
https://msdn.Microsoft.com/en-us/library/ms188332.aspx
Modifier:
J'ai trouvé l'article suivant concernant les performances:
La performance est un sujet de débat entre ces deux méthodes pour les procédures stockées. Comme son nom l'indique, sp_execute Est lui-même une procédure stockée, qui est stockée dans la base de données système. SP_ExecuteSQL Doit donc lui passer des chaînes SQL, sauf pour montrer des chances plus élevées de mise en cache, ce qui conduit par conséquent à de meilleures performances lorsqu'il est exécuté pour la deuxième fois ou plus tard.
En d'autres termes, son T-SQL dynamique paramétré encourage sa réutilisation. De plus, sp_execute est supposé avoir plus de chances d'éviter une compilation inutile lors de l'exécution d'une requête dynamique sur exec(). Mais certains experts le considèrent aussi trompeur qu'ils le pensent pour les deux méthodes, un plan sera mis en cache. En fait, pour les requêtes non paramétrées de SP_ExecuteSQL Montre les mêmes caractéristiques que la dernière.
http://www.technovisitors.com/2014/07/SPExecuteSQL-Vs-Execute-SQL-Server.html
EXEC utilise le cache ad hoc et peut provoquer un gonflement de plan ad hoc, contrairement à sp_executesql, selon la stabilité de vos plans.