Comment prouver que l'aide de requêtes SQL dans sous-requête tue les performances du serveur

Question

L'un de mes emplois pour maintenir notre base de données, le plus souvent nous avons des problèmes avec le manque de performances tout en obtenant des rapports et de travail Whit cette base.
Quand je commence à regarder les requêtes que notre ERP d'envoi à la base de données que je vois beaucoup de requêtes totalement inutilement à l'intérieur des requêtes principales sous-requête.
Comme je ne suis pas membre de développeurs qui est créateur de programme, nous en utilisant, ils ne le font pas comme beaucoup quand je critique leur code et l'emploi. Disons qu'ils ne prendre mon examen comme des déclarations graves. Je vous demande quelques questions sur subselect dans SQL

Est-ce que subselect prend beaucoup de plus de temps puis à gauche jointures externes?
Est-ce que existe un blog, un article ou quoi que ce soit où je subselect est recommandé de ne pas utiliser
Comment puis-je prouver que si nous évitons subselesct dans la requête que la requête va être plus rapide?

Notre serveur de base de données est MSSQL2005

Answer 1

"Show, Do not Tell" - voir et de comparer les plans d'interrogation des requêtes identifiées à l'aide de profils SQL. regarder particulièrement pour les analyses de table et de signet lookups (vous voulez voir l'index cherche aussi souvent que possible). La « qualité de l'ajustement » des plans de requête dépend de statistiques mises à jour, quels index sont définis, la charge de travail de recherche globale.

• exécution de base plan

• Comprendre plus complexes des plans de requête

• Utilisation de profils SQL Server (2005 version)

Exécuter les requêtes dans SQL Server Management Studio (SSMS) et activer Query-> Inclure plan d'exécution réel (CTRL + M)

Pensez-vous chanceux ils sont seulement subselects (qui, dans certains cas, le Optimiseur produira l'équivalent « joindre plans ») et non corrélé sous-requêtes!

Identifier une requête qui effectue un grand nombre de lectures logiques, ré-écrire en utilisant votre technique préférée, puis montrer comment quelques Logicals lit qu'il fait par comparaison.

Voici une astuce. Pour obtenir le nombre total de lectures effectuées logique, enveloppez une requête en question avec:

SET STATISTICS IO ON
GO

-- Run your query here

SET STATISTICS IO OFF
GO

Exécuter votre requête, et passez à l'onglet messages dans le volet des résultats.

Si vous souhaitez en savoir plus, il n'y a pas de meilleur livre que SQL Server 2008 Performance Tuning requête Distilled, qui couvre les techniques essentielles pour le suivi, l'interprétation et la résolution des problèmes de performance.

Answer 2

Une chose que vous pouvez faire est de charger SQL Profiler et leur montrer le coût (en termes de cycles CPU, lit et écrit) des sous-requêtes. Il est difficile de discuter avec le froid, de statistiques précises.

Je vérifie également le plan de requête pour ces requêtes pour réaliser des index appropriés que sont utilisés, et les analyses de table / index sont détenus au minimum.

En général, je ne dirais pas que les sous-requêtes sont mauvaises, si elle est utilisée correctement et les indices appropriés sont en place.

Answer 3

Je ne suis pas très familier avec MSSQL, comme nous utilisons postrgesql dans la plupart de nos applications. Cependant, il devrait exister quelque chose comme « Explain » qui vous montre le plan d'exécution de la requête. Il vous devriez être en mesure de voir les différentes étapes qu'une requête produira afin de récupérer les données nécessaires.

Si vous voyez qu'il ya beaucoup de scans de table ou jointure de boucle sans utilisation de l'index, il est certainement un indice pour une exécution de la requête lente. Avec l'outil d'un tel, vous devriez être en mesure de comparer les deux requêtes (une avec la jointure, l'autre sans)

Il est difficile d'affirmer quelle est la meilleure façon, parce que cela dépend vraiment fortement des indices l'optimiseur peut prendre dans les différents cas et en fonction du SGBD l'optimiseur peut être en mesure de réécrire implicitement une sous-requête-requête dans une jointure -query et l'exécuter.

Si vous voulez vraiment montrer ce qui est mieux que vous devez exécuter les deux et mesurer le temps, cpu-usage et ainsi de suite.

Mise à jour: Il est probablement celui-ci pour MSSQL -> plan d'exécution

Answer 4

De ma propre expérience les deux méthodes peuvent être valides, comme par exemple un EXISTE subselect peut éviter beaucoup de traitement avec une rupture précoce.

la plupart des Buts requêtes de temps avec beaucoup de subselect sont faites par les devs qui ne comprennent pas vraiment SQL et utilisent leur chemin-programmeur procédure classique de réflexion sur les requêtes. Ensuite, ils ne pensent même pas sur les jointures, et fait des requêtes horribles. Je préfère donc rejoint, et je vérifie toujours les sous-requêtes. Pour être complètement honnête je suivre les requêtes lentes, et mon premier essai sur les requêtes lentes contenant des sous-requêtes est en train de faire des jointures. Fonctionne beaucoup de temps.

Mais il n'y a pas de règles qui peuvent prouver subselect sont mauvais ou plus lent que les jointures, il est juste que le mauvais programmeur sql souvent faire des sous-requêtes: -)

Answer 5

  

Est-ce que subselect prend beaucoup plus de temps de jointures externes puis à gauche?

Cela dépend de la sous-sélection et des jointures externes gauche.

En général, cette construction:

SELECT  *
FROM    mytable
WHERE   mycol NOT IN
        (
        SELECT  othercol
        FROM    othertable
        )

est plus efficace que ceci:

SELECT  m.*
FROM    mytable m
LEFT JOIN
        othertable o
ON      o.othercol = m.mycol
WHERE   o.othercol IS NULL

Voir ici:

• PAS contre EXISTE PAS contre LEFT JOIN / IS NULL: SQL Server

  

existe-t un blog, un article ou quoi que ce soit où subselect est recommandé de ne pas utiliser?

J'éviter des blogs qui recommandent aveuglément à éviter les sous-requêtes.

Ils sont mis en œuvre pour une raison et, croyez-le ou non, les développeurs ont mis un certain effort dans les optimiser.

  

Comment puis-je prouver que si nous évitons subselesct dans la requête que la requête va être plus rapide?

Ecrire une requête sans les sous-requêtes qui tourne plus vite.

Si vous postez votre demande ici nous sera peut-être en mesure d'améliorer. Cependant, une version avec les sous-requêtes peut se révéler plus rapide.

Answer 6

Essayez de réécrire certaines des requêtes pour éliminer le sous-sélectionner et comparer runtimes.

Partager et apprécier.