J'ai créé des vues pour mon projet. Maintenant, je veux les optimiser pour la vitesse ... Comment puis-je identifier que la vue peut être optimiser? Est index utile pour cela?
Disons l'exemple suivant ... où est-il possible d'optimiser cette vue? vm_webtopbids et vm_webinventory sont deux vues différentes ...
3 Réponses :
Une vue est une macro élargie dans la requête extérieure. Sauf si c'est une vue indexée et que vous avez une édition d'entreprise, il est simplement ignoré.
Donc, si vous rejoignez 3 vues et que chaque vues utilise 5 tables, vous avez une grande jointure avec 15 tables.
Vous avez le meilleur choix Tuning de la base de données ou index manquant Script: éditer, après l'exemple Vous imbriquez des vues sur des vues. Aucune optimisation n'est possible de la vue elle-même. Comme mentionné, cela ne peut pas être indexé
L'ajout d'index à la vue est utile pour optimiser la vitesse?
@girish: Il est difficile de dire sans plus d'informations. Personnellement, j'utiliserais le DTA ou le script ci-dessus avant que je considère des vues indexées
Les vues indexées peuvent être utilisées dans les éditions SQL Server autres que l'entreprise, mais vous devez fournir à la requête NOEXPAND dans une requête qui fait référence à l'affichage, sinon l'index sera ignoré.
Dans ce cas, la vue ne peut pas être indexée car elle contient une jointure extérieure.
Voir cet article pour plus d'informations sur les vues d'indexation et les (nombreuses) restrictions sur elles: http://technet.microsoft.com/en-us/library/cc917715.aspx
Est-ce que cela signifie, ci-dessus la vue est perfactive tel quel ... il ne peut plus être optimiser
Dépend trop de choses à dire. Comme suggéré ailleurs, envisagez d'optimiser les tables sous-jacentes en premier. Si le motif d'accès doit utiliser l'avis de manière approfondie de sorte que l'amélioration de cette vue gree les plus gros avantages, voir si vous pouvez le modifier afin qu'il réponde aux contraintes d'affichage indexées, puis ajoutez des index appropriés.
Vues de nidification appelant d'autres vues est une technique extrêmement mauvaise pour la performance. Comme il ne peut pas être indexé, il doit appeler toute la vue sous-jacente afin d'obtenir celui-ci que le sommet reviendrait. De plus, vous éventuellement, vous obtenez suffisamment de couches et vous appuyez sur la limite du nombre de tables que vous pouvez appeler dans une vue (et si View1 appelle View2 et View3 et appelez les mêmes tables sous-jacentes que vous vous joignez deux fois au lieu de la fois, ce qui est souvent mauvais pour Performance. Arrêtez d'appeler des vues de vues ou vous aurez un système inutilisable.
Nous repensons complètement un système comme celui-ci, car les développeurs d'applications l'ont fait et que le client de plusieurs millions de dollars nous quittera à moins que la performance s'améliore et que nous ne puissions pas l'améliorer avec cette judicule, alors maintenant une Terminez la refonte que le client ne paiera pas car l'erreur était la nôtre. Ne descends pas cette route. Arrêter maintenant. Vues qui appellent des vues sont très très mauvaises.
@HLGEM Étant donné que votre réponse a plus de 8 ans, je souhaite vérifier si la vue Les tables d'appel et autres vues de différentes bases de données soient optimisées dans les dernières versions SQL Server?