Pourquoi la procédure stockée est plus rapide que la requête
Je veux écrire une simple requête sur une seule ligne pour sélectionner une seule valeur dans la base de données.
Donc, si j'écris des procédures stockées pour cette requête plutôt que d'écrire une requête de sélection simple en code c #, je suis sûr que la procédure stockée pour cette requête de sélection simple sera plus rapide, mais pourquoi?
Je suis confus avec la procédure stockée vs l'écriture d'une requête simple dans mon code? Je suis confus: pourquoi la procédure stockée est-elle plus rapide qu'une simple requête écrite directement dans le code?
Les procédures stockées sont plus rapides que le code SQL
Il s'agit d'un mythe , les performances sont toujours équivalentes, d'après le livre: Architecting Microsoft® .NET Solutions for the Enterprise:
SQL est un langage par lequel vous déclarez vos intentions concernant les opérations (requête, mise à jour ou opérations de gestion) à exécuter sur la base de données. Tout ce que le moteur de base de données obtient est du texte. Tout comme un fichier source C # traité par un compilateur, le code source SQL doit être compilé d'une manière ou d'une autre pour produire une séquence d'opérations de base de données de niveau inférieur - cette sortie passe sous le nom de plan d'exécution. Conceptuellement, la génération du plan d'exécution peut être considérée comme la contrepartie de la base de données de la compilation d'un programme.
Le gain de performances allégué que les procédures stockées garantissent par rapport au code SQL brut réside dans la réutilisation du plan d'exécution. En d'autres termes, la première fois que vous exécutez un SP, le SGBD génère le plan d'exécution puis exécute le code. La prochaine fois, il réutilisera simplement le plan généré précédemment, exécutant ainsi la commande plus rapidement. Toutes les commandes SQL nécessitent un plan d'exécution.
Le (faux) mythe est qu'un SGBD réutilise le plan d'exécution uniquement pour les procédures stockées. En ce qui concerne SQL Server et Oracle DBMS, l'avantage de la réutilisation des plans d'exécution s'applique à toutes les instructions SQL. Citant de la documentation en ligne de SQL Server 2005:
Lorsqu'une instruction SQL est exécutée dans SQL Server 2005, le moteur relationnel examine d'abord le cache de procédure pour vérifier qu'un plan d'exécution existant pour la même instruction SQL existe. SQL Server 2005 réutilise tout plan existant qu'il trouve, économisant ainsi la surcharge de recompilation de l'instruction SQL. S'il n'existe aucun plan d'exécution existant, SQL Server 2005 génère un nouveau plan d'exécution pour la requête.
Le débat autour des performances supérieures des SP que du code SQL brut est inutile. En termes de performances, tout code SQL qui atteint la base de données est traité de la même manière. Les performances sont équivalentes une fois compilées. Période.
Cela dépend de la requête, pour les requêtes simples, il vaut mieux l'écrire et l'exécuter en tant que requête elle-même. Cependant, lorsque vous avez plus de traitement à faire du côté de la base de données (vous voulez que les données soient manipulées par un curseur, etc.), les procédures stockées sont meilleures car elles s'exécutent sur le serveur de base de données et évitent les surcharges inutiles telles que l'analyse et la communication supplémentaire .
"Stored procedures are precompiled and cached so the performance is much better."
Cela m'a brisé le cœur comme ce le serait pour vous lorsque vous apprenez que cela était vrai jusqu'à SQL Server 2005. Cet article brise le mythe Les procédures stockées N'augmentent PAS les performances
Christa Carpentiere de Microsoft Corp. a écrit ne évaluation des procédures stockées pour le développeur .NET