Pourquoi serait à l'aide d'une table temp être plus rapide qu'une requête imbriquée?
Nous essayons d'optimiser certains de nos requêtes.
Une requête est de faire ce qui suit:
SELECT t.TaskID, t.Name as Task, '' as Tracker, t.ClientID, (<complex subquery>) Date,
INTO [#Gadget]
FROM task t
SELECT TOP 500 TaskID, Task, Tracker, ClientID, dbo.GetClientDisplayName(ClientID) as Client
FROM [#Gadget]
order by CASE WHEN Date IS NULL THEN 1 ELSE 0 END , Date ASC
DROP TABLE [#Gadget](J'ai enlevé le complexe sous-requête. Je ne pense pas que c'est pertinent autre que d'expliquer pourquoi cette requête a été fait comme un processus en deux étapes.)
Je pensée il serait bien plus efficace de cette fusion en une seule requête à l'aide de sous-requêtes comme:
SELECT TOP 500 TaskID, Task, Tracker, ClientID, dbo.GetClientDisplayName(ClientID)
FROM
(
SELECT t.TaskID, t.Name as Task, '' as Tracker, t.ClientID, (<complex subquery>) Date,
FROM task t
) as sub
order by CASE WHEN Date IS NULL THEN 1 ELSE 0 END , Date ASCCe serait donner à l'optimiseur de meilleure information pour savoir ce qui se passait et d'éviter toutes les tables temporaires. Je suppose qu'il devrait être plus rapide.
Mais il s'avère qu'il est beaucoup plus lent. 8 secondes, contre moins de 5 secondes.
Je ne peux pas savoir pourquoi ce serait le cas, toutes mes connaissances de bases de données implique que les sous-requêtes serait toujours plus rapide que d'utiliser des tables temporaires.
Ce qui me manque?
Modifier --
De ce que j'ai pu voir les plans de requête, les deux sont en grande partie identiques, sauf pour la table temporaire qui a une "Table d'Insérer" de l'opération, d'un coût de 18%.
Évidemment, comme il y a deux requêtes le coût de la Sorte en Haut N est beaucoup plus élevé dans la deuxième requête que le coût de la Sorte dans la sous-Requête de la méthode, de sorte qu'il est difficile de faire une comparaison directe des coûts.
Tout ce que je peux le voir sur les plans indiquent que la sous-requête méthode serait plus rapide.
voir mon edit.
Avez-vous effacer la mémoire cache des données entre chaque test? Si non, qui pourraient biaiser la comparaison
En effet; plan de requête est la première chose à regarder, que vais vous dire exactement ce qu'il se passe. Aussi, la mémoire peut être un facteur; je suppose que la version combinée peut utiliser plus de mémoire, mais qu'il serait difficile de dire sans détaillée à la recherche. Aussi, pas trop applicable ici avec deux requêtes-en-un, mais si vous n'êtes pas à l'aide de SQL Server propre requête à l'optimisation de l'assistant de truc, je vous recommande de commencer, car il est généralement assez bonne.
OriginalL'auteur Mongus Pong | 2010-05-13
Vous devez vous connecter pour publier un commentaire.
Évidemment, SQL Server est un mauvais choix de plan de requête. Oui, ça peut arriver, j'ai eu exactement le même scénario que vous avez un peu de temps.
Le problème, c'est que l'optimisation d'une requête (tu parles d'un "complexe de sous-requête") est une tâche non triviale: Si vous avez n tables, il y a à peu près n! commandes jointure possible -- et ce n'est que le début. Donc, il est tout à fait plausible que le fait (a) d'abord votre requête interne et (b) votre requête externe est une bonne façon d'aller, mais SQL Server ne peut pas déduire cette information dans un délai raisonnable.
Ce que vous pouvez faire est de aider SQL Server. Comme Dan Remorquage écrit dans son grand livre "SQL Tuning", la clé est généralement de l'ordre de jointure, en allant de la plus sélective pour le moins sélective table. En utilisant le bon sens (ou la méthode décrite dans son livre, ce qui est beaucoup mieux), vous pouvez déterminer l'ordre de jointure serait la plus appropriée, puis d'utiliser la
FORCEindicateur de requête.De toute façon, chaque demande est unique, il n'y a pas de "bouton magique" pour faire du SQL Serveur plus rapide. Si vous voulez vraiment savoir ce qui se passe, vous avez besoin de regarder (ou nous montrer) les plans de requête de vos requêtes. D'autres données intéressantes est indiqué par SET STATISTICS IO, qui vous indiquera la quantité de (coûteux) de l'accès au disque dur de votre requête produit.
OriginalL'auteur Heinzi
"doit être" n'est pas une mince chose à dire de la performance de base de données. J'ai souvent constaté que les tables temporaires d'accélérer les choses, parfois de façon spectaculaire. L'explication simple est que cela rend plus facile pour l'optimiseur pour éviter la répétition des travaux.
Bien sûr, j'ai aussi vu des tables temporaires rendre les choses plus lentement, parfois beaucoup plus lent.
Il n'y a pas de substitut à des fins de profilage et d'étudier les plans de requête (lire leurs estimations avec un grain de sel, tout de même).
OriginalL'auteur Marcelo Cantos
J'ai réitéré cette question ici: Comment puis-je la force d'une sous-requête à effectuer ainsi que d'une table #temp?
Le point essentiel de il est, oui, je reçois que, parfois, l'optimiseur est en droit de se mêler avec votre sous-requêtes, comme si elles n'étaient pas entièrement autonome, mais parfois, il en fait un mauvais mal tourner quand il essaie d'être intelligent dans un sens que nous sommes tous familiers avec. Je veux dire, il doit y avoir un moyen de désactiver cette "intelligence" lorsque nécessaire, au lieu de la démolition d'un Affichage led approche avec des tables temporaires.
OriginalL'auteur Adamantish