SQL Query Costing, l'agrégation d'une vue est plus rapide?

J'ai une table Sheet1 $ qui contient 616 loggings. J'ai une autre table, Rates $ qui contient 47880 loggings. Taux contient un taux de réponse pour un logging donné dans la feuille pendant 90 jours à partir d'une date d'envoi. Au cours de tous les 90 jours d'une relation tarifaire, la réponse totale est TOUJOURS de 1 (100%)

Exemple:

Sheet1$: Record 1, 1000 QTY, 5% Response, Mail 1/1/2009 Rates$: Record 1, Day 1, 2% Response Record 1, Day 2, 3% Response Record 1, Day 90, 1% Response Record N, Day N, N Response

Donc, dans ce cas, j'ai écrit une vue qui prend ces tables et les joint à droite sur les taux pour développer datatables afin que je puisse effectuer quelques calculs pour get un rendement par jour pour un logging donné.

 SELECT s.[Mail Date] + r.Day as Mail_Date, s.Quantity * s.[Expected Response Rate] * r.Response as Pieces, s.[Bounce Back Card], s.Customer, s.[Point of Entry] FROM Sheet1$ as s RIGHT OUTER JOIN Rates$ as r ON s.[Appeal Code] = r.Appeal WHERE s.[Mail Date] IS NOT NULL AND s.Quantity <> 0 AND s.[Expected Response Rate] <> 0 AND s.Quantity IS NOT NULL AND s.[Expected Response Rate] IS NOT NULL);

Donc, je l'enregistre comme une vue appelée Test_Results. À l'aide de SQL Server Management Studio, j'exécute cette requête et obtient un résultat de 211 140 loggings. Le time écoulé était de 4.121 secondes, Est. Le coût du sous-tree était de 0,751.

Maintenant, je lance une requête sur cette vue pour agréger un nombre de pièces chaque jour.

 SELECT Mail_Date, SUM(Pieces) AS Piececount FROM Test_Results GROUP BY Mail_Date

Cela renvoie 773 lignes et il n'a fallu que 0,452 secondes pour s'exécuter! 1.458 Est. Coût du sous-tree.

Ma question est, avec une estimation plus élevée, comment cela a-t-il fonctionné beaucoup plus vite que la vue originale elle-même ?! Je suppose qu'un morceau pourrait être que ses lignes de return au studio de gestion. Si tel est le cas, comment pourrais-je voir le coût réel de cette requête sans avoir à tenir count du return d'information?

SELECT * FROM view1 aura un plan

SELECT * FROM view2 (où view2 est basé sur view1) aura son propre plan complet

L'optimiseur est assez intelligent pour que le plan pour view2 combine / réduit les opérations en une opération plus efficace. Il va seulement observer la sémantique de la design de view1, mais il n'est pas nécessairement nécessaire d'utiliser le plan pour SELECT * FROM view1 et d'appliquer un autre plan pour view2 – ce sera, en général, un plan complètement différent, et il fera tout ce qu'il peut pour get les résultats les plus efficaces.

Généralement, cela va réduire l'agrégation pour améliorer la sélectivité et réduire les besoins en données, ce qui accélérera l'opération.

Les coûts des requêtes sont sans unité et sont simplement utilisés par l'optimiseur pour choisir ce qu'il pense être le path d'exécution le plus efficace pour une requête particulière. Ils ne peuvent pas vraiment être comparés entre les requêtes. Ceci , bien que vieux, est une bonne lecture rapide. Ensuite, vous aurez probablement envie de chercher des livres ou des articles sur l'optimiseur MSSQL et sur la lecture des plans de requête si vous êtes vraiment intéressé.

(Assurez-vous également que vous visualisez le plan d'exécution réel, et non le plan d'explication … ils peuvent être différents)

Je pense que Cade a couvert la partie la plus importante – la sélection à partir d'une vue n'implique pas nécessairement le return de toutes les lignes de vue et ensuite la sélection contre cela. SQL Server optimisera la requête globale.

Pour répondre à votre question, si vous voulez éviter le réseau et afficher les coûts, vous pouvez simplement sélectionner chaque résultat de la requête dans un tableau. Ajoutez simplement "INTO Some_Table" après la list des colonnes dans la clause SELECT.

Vous devriez également être capable de séparer les choses en affichant des statistics client ou en utilisant Profiler, mais la méthode SELECT … INTO est rapide et facile.