Nous essayons d'optimiser certaines de nos questions.
Une requête fait ce qui suit: p> (j'ai supprimé la sous-requête complexe. Je ne pense pas que ce soit pertinent autre que d'expliquer pourquoi cette requête a été faite En tant que processus à deux étapes.) p> i pensé em> Il serait beaucoup plus efficace de fusionner cela dans une seule requête à l'aide de sous-requêtes telles que: P> 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 ASC
3 Réponses :
"devrait être" est une chose dangereuse à dire de la performance de la base de données. J'ai souvent trouvé que les tables temporaires de Temp accélérent des choses, parfois dramatiquement. L'explication simple est qu'elle facilite l'optimiseur d'éviter de répéter le travail.
Bien sûr, j'ai aussi vu des tables temporaires à rendre les choses plus lentes, parfois beaucoup plus lentes.
Il n'y a pas de substitut au profilage et à l'étude des plans de requête (lire leurs estimations avec un grain de sel, cependant).
Évidemment, SQL Server choisit le mauvais plan de requête. Oui, cela peut arriver, j'ai eu exactement le même scénario que vous quelques fois.
Le problème est que l'optimisation d'une requête (vous mentionnez une "sous-requête complexe") est une tâche non triviale: si vous avez n tables, il y a grossièrement n! Des commandes de jointure possibles - et ce n'est que le début. Donc, il est assez plausible que faire (a) votre requête intérieure et (b), alors votre requête externe est un bon moyen d'aller, mais SQL Server ne peut pas déduire ces informations dans un délai raisonnable.
Ce que vous pouvez faire est de aide SQL Server. Comme Dan Tow écrit dans son excellent livre " SQL Tuning ", la clé est généralement la commande de jointure, passant du plus sélectif à la table la moins sélective. Utilisation de bon sens (ou la méthode décrite dans son livre, qui est bien meilleure), vous pouvez déterminer quelle commande de jointure serait la plus appropriée, puis utilisez le Quoi qu'il en soit, chaque requête est unique, il n'y a pas de "bouton magique" pour rendre SQL Server plus rapidement. Si vous voulez vraiment savoir ce qui se passe, vous devez regarder (ou vous montrer) les plans de requête de vos questions. SET STATISTIQUES IO , qui vous dira Combien (coûteux) HDD accède à votre requête produit. Commande de force indice de requête.
J'ai réinitialisé cette question ici: Comment puis-je forcer une sous-requête à effectuer ainsi qu'une table #Temp?
Le nœud de celui-ci est, oui, je reçois que parfois l'optimiseur ait raison de se mêler de vos sous-requêtes comme s'ils n'étaient pas entièrement autonomes, mais parfois, cela fait un mauvais tour lorsqu'il essaie d'être intelligent d'une manière que nous connaissons tous avec. Je dis qu'il doit y avoir un moyen d'éteindre cette "intelligence" si nécessaire au lieu de détruire une approche menée par la vue avec des tables Temp.
Juste pour mettre à jour. Martin Smith a fourni une réponse qui a fonctionné pour moi en pointant ici: connect.microsoft.com/ SQLServer / Feedback / Détails / 218968 Il est susceptible d'avoir fixé le problème de ce demandeur, bien que Martin a souligné qu'une bobine n'a pas de statistiques comme les tables Temps et c'est un piratage qui nécessite une ordonnance par laquelle pourrait entraîner un coût réel. pour certains.
Avez-vous comparé des plans de requête?
Avez-vous effacé le cache de données entre chaque test? Sinon, cela pourrait pénétrer votre comparaison
En effet; Le plan de requête est la première chose à regarder, car cela vous dira exactement ce qui se passe. En outre, la mémoire peut être un facteur; Je suppose que la version combinée peut utiliser plus de mémoire, mais ce serait difficile de dire sans que ce soit. Aussi - pas trop applicable ici avec deux questions-en-une, mais si vous n'utilisez pas l'assistant d'optimisation de la requête de SQL Server, je vous recommande de commencer, car il est généralement assez bon.