Performances SQL-Server: Qu'est-ce qui est plus rapide, une procédure stockée ou une vue?
Qu'est-ce qui est plus rapide dans SQL Server 2005/2008, une procédure stockée ou une vue?
EDIT: Comme beaucoup d’entre vous l’ont souligné, je suis trop vague. Permettez-moi d’être un peu plus précis.
Je voulais connaître la différence de performances pour une requête particulière dans une vue, par opposition à la même requête identique dans une procédure stockée . (J'apprécie toujours toutes les réponses qui soulignent leurs capacités différentes)} _
Les procédures stockées (SP) et les vues SQL sont des "bêtes" différentes, comme indiqué à plusieurs reprises dans ce message.
Si nous excluons certaines considérations de performance [généralement mineures, à l'exception des cas marginaux] associées à la mise en cache du plan de requête, le temps associé à la liaison à une procédure stockée et autres, les deux approches sont globalement équivalentes, performance- sage. Cependant ...
Une vue est limitée à tout ce qui peut être exprimé dans une seule instruction SELECT (enfin, éventuellement, avec des CTE et quelques astuces), mais en général, une vue est liée à des formes déclaratives de requêtes. Une procédure stockée de l’autre peut utiliser diverses constructions de type procédural (ainsi que des déclarations), et en conséquence, en utilisant des SP, on peut créer à la main un moyen de résoudre une requête donnée qui peut être plus efficace que ce que l'optimiseur de requêtes de SQL-Server aurait pu faire (sur la base d'une requête déclarative unique). Dans ces cas, un SP peut être beaucoup plus rapide (mais méfiez-vous ... l'optimiseur est plutôt intelligent et il ne faut pas beaucoup pour rendre un SP beaucoup plus lent que la vue équivalente.)
Outre ces considérations de performances, les SP sont plus polyvalents et permettent un plus grand nombre d'enquêtes et d'actions que les vues.
Malheureusement, ils ne sont pas le même type de bête.
Une procédure stockée est un ensemble d'instructions T-SQL et CAN peut renvoyer des données. Il peut effectuer toutes sortes de logique et ne renvoie pas nécessairement de données dans un jeu de résultats.
Une vue est une représentation de données. Il est principalement utilisé comme une abstraction d'une ou de plusieurs tables avec des jointures sous-jacentes. C'est toujours un résultat de zéro, une ou plusieurs lignes.
Je soupçonne que votre question va plus dans le sens de:
Laquelle est la plus rapide:
SELECTing à partir d’une vue ou l’instructionSELECTéquivalente dans une procédure stockée, étant donné que les mêmes tables de base effectuent les jointures avec les mêmes clauses where?
Ce n'est pas vraiment une question à résoudre dans la mesure où une réponse sera vraie dans tous les cas. Cependant, en tant que réponse générale à une implémentation spécifique à SQL Server ...
En général, une procédure stockée a de bonnes chances d'être plus rapide qu'une instruction SQL directe car le serveur effectue toutes sortes d'optimisations lorsqu'une procédure stockée est enregistrée et exécutée pour la première fois.
Une vue est essentiellement une instruction SQL enregistrée.
Par conséquent, je dirais qu'en général, une procédure stockée sera probablement plus rapide qu'une vue SI l'instruction SQL pour chaque opération est identique, et SI l'instruction SQL peut bénéficier d'optimisations. Sinon, en général, leur performance serait similaire.
Référencez ces liens à la documentation supportant ma réponse.
http://www.sql-server-performance.com/tips/stored_procedures_p1.aspx
http://msdn.Microsoft.com/en-us/library/ms998577.aspx
De plus, si vous recherchez tous les moyens d'optimiser les performances sur SQL Server, le deuxième lien ci-dessus est un bon point de départ.
Je préfère les procédures stockées pour permettre un meilleur contrôle des données. Si vous souhaitez créer un bon système modulaire sécurisé puis utiliser des procédures stockées, il peut exécuter plusieurs commandes SQL, avoir des instructions de contrôle du flux et accepter les paramètres. Tout ce que vous pouvez faire dans une vue que vous pouvez faire dans une procédure stockée. Mais dans une procédure stockée, vous pouvez faire avec beaucoup plus de flexibilité.
En bref, sur la base de mon expérience dans des requêtes complexes, la procédure stockée offre de meilleures performances que la fonction.
Mais vous ne pouvez pas utiliser les résultats de la procédure stockée dans des requêtes select ou join.
Si vous ne souhaitez pas utiliser le jeu de résultats dans une autre requête, utilisez plutôt SP.
Et le reste des détails et des différences est mentionné par les gens de ce forum et d'ailleurs.
Les procédures stockées et les vues sont différentes et ont des objectifs différents. Je regarde les vues comme des requêtes en boîte. Je regarde les procédures stockées en tant que modules de code.
Par exemple, supposons que vous ayez une table appelée tblEmployees avec ces deux colonnes (entre autres): DateOfBirth et MaleFemale.
Une vue appelée viewEmployeesMale qui filtre uniquement les employés de sexe masculin peut être très utile. Une vue appelée viewEmployeesFemale est également très utile. Ces deux vues sont auto-descriptives et très intuitives.
Supposons maintenant que vous deviez produire une liste de tous les employés de sexe masculin âgés de 25 à 30 ans. J'aurais tendance à créer une procédure stockée pour obtenir ce résultat. Bien qu’elle puisse très certainement être construite sous forme de vue, à mon avis, une procédure stockée convient mieux à cette situation. La manipulation des dates, en particulier lorsque les valeurs nulles sont un facteur, peut devenir très délicate.
Je pense qu'une autre façon de penser serait d'utiliser des procédures stockées pour sélectionner les vues. Cela fera de votre architecture un système faiblement couplé. Si vous décidez de modifier le schéma à l'avenir, vous n'aurez pas à vous inquiéter de manière excessive.
Je suppose que ce que je dis, c’est au lieu de sp vs vues, pense sp et views :)
Quelques considérations supplémentaires: Bien que les performances entre un SP et une vue soient essentiellement identiques (étant donné qu'elles effectuent exactement la même sélection), le SP vous donne plus de flexibilité pour cette même requête.
- Le SP prendra en charge la commande du jeu de résultats. c'est-à-dire, y compris une déclaration ORDER BY. Vous ne pouvez pas le faire dans une vue.
- Le SP est entièrement compilé et nécessite seulement un exec pour l'invoquer. La vue nécessite toujours un
SELECT * FROM viewpour l'appeler; c'est-à-dire une sélection sur la sélection compilée dans la vue.
Je sais que je ne suis pas censé transformer cela en une "discussion", mais cela m'intéresse beaucoup et je pensais juste partager mes observations empiriques sur une situation spécifique, avec une référence particulière à tous les commentaires ci-dessus qui indiquent que une instruction SELECT équivalente exécutée à partir d'une procédure stockée et d'une vue doit globalement avoir les mêmes performances.
J'ai une vue dans la base de données "A" qui joint 5 tables dans une base de données séparée (db "B"). Si j'attache à la base de données "A" dans SSMS et à l'option SELECT * de la vue, il faut plus de 3 minutes pour obtenir 250000 lignes. Si je prends l'instruction select de la page de conception de la vue et l'exécute directement dans SSMS, cela prend <25 secondes. Mettre la même instruction select dans une procédure stockée donne les mêmes performances lorsque j'exécute cette procédure.
Sans faire d’observations sur les performances absolues (la base de données "B" est une base de données AXE à laquelle nous ne sommes pas autorisés à toucher!), Je suis toujours absolument convaincu que dans ce cas, utiliser un SP est un ordre de grandeur plus rapide que utiliser une vue pour récupérer les mêmes données, et cela s'applique à de nombreuses autres vues similaires dans ce cas particulier.
Je ne fais pas pense c'est quelque chose à voir avec la création d'une connexion à l'autre base de données, sauf si vous utilisez une vue, vous ne pourrez jamais mettre la connexion en cache, contrairement à la sélection, car je peux basculer entre les 2 sélections la même fenêtre SSMS à plusieurs reprises et les performances de chaque requête restent cohérentes. De plus, si je me connecte directement à la base de données "B" et que je lance la sélection sans le nom de base.dbo .... refs, le processus prend le même temps.
Des pensées quelqu'un?