Inline requête rapport avec clause de problème de performance
J'ai une requête à la structure un peu comme ci-dessous:
select (select first_name
from sub_table_1,
sub_table_2,
sub_table_3
where <where clause for sub_table 1,2,4>
and sub_table_1.col_1=table_1.col_1) first_name ,
(select last_name
from sub_table_1,
sub_table_2,
sub_table_3
where <where clause for sub_table 1,2,4>
and sub_table_1.col_1=table_1.col_1) last_name ,
<other select clause for table 1,2,3>
from table_1,
table_2,
table_3
where <Where clauses>
union
select (select first_name
from sub_table_1,
sub_table_2,
sub_table_3
where <where clause for sub_table 1,2,3>
and sub_table_1.col_1=table_4.col_1) first_name ,
(select last_name
from sub_table_1,
sub_table_2,
sub_table_3
where <where clause for sub_table 1,2,3>
and sub_table_1.col_1=table_4.col_1) last_name ,
<other select clause for table 4,5,6>
from table_4,
table_5,
table_6
where <Where clauses>
Je veux comme je savoir si la prise de la partie:
(select first_name , last_name
from sub_table_1,
sub_table_2,
sub_table_3
where <where clause for sub_table 1,2,3>
and sub_table_1.col_1=table_4.col_1) first_name ,
(select last_name
from sub_table_1,
sub_table_2,
sub_table_3
where <where clause for sub_table 1,2,3> )
va m'aider à en faire la requête plus rapide et mieux ou va affecter.
également noter que, cette sous-requête peut récupérer environ 10000 enregistrements en elle-même.
s'il vous plaît aider
- Essayer les deux. Laissez-nous savoir laquelle est la plus rapide.
- Sans réponse, à moins que la requête est fourni. En tout cas, deux choses: utilisez des Jointures internes et fossé des sous-requêtes.
Vous devez vous connecter pour publier un commentaire.
Expressions de Table communes (la clause) ont, autant que je sache, deux impacts potentiels sur la requête.
Ils permettent à l'optimiseur de concrétiser l'ensemble de résultats, de manière efficace de créer une table temporaire pour contenir le résultat. Les conditions dans lesquelles il fait ce ne sont pas documentés pour autant que je sais, mais j'ai lu qu'il se passe, si la taille de l'ensemble dépasse le tri de la taille de la zone de la session, et si le résultat devrait être utilisé plus d'une fois dans la requête.
Il y a parfois des bugs associés avec CTE requête d'optimisation.
Donc la performance sage, si vous avez un grand ensemble de résultats, qui est utilisé muttiple fois alors je vous envisager un meilleur candidat pour un CTE.
J'ai tendance à utiliser beaucoup dans Oracle et PostgreSQL, car je trouve qu'ils font du code beaucoup plus clair que d'avoir imbriqué inline vues.
Si vous continuez à faire comme les sous-requêtes, à l'aide d'un CTE /AVEC clause est peu susceptible d'affecter la performance de toute façon puisque l'interprète de SQL permettra de développer efficacement sur le long formulaire à de telles fins (ie. où ne pas utiliser les expressions cte), l'utilisation d'expressions de table communes est effectivement une façon d'écrire du code qui est plus SÈCHE.
Pour en être certain, de comparer le plan de requête produite par les deux versions.
Dans les deux cas, la structure de la requête est extrêmement inefficace, car elle est effectivement à l'exécution de chacune des sous-requête séparément pour chaque ligne retournée dans la requête principale.
De mon expérience dans 11gR2, à l'aide d'une clause peut être plus lent. L'indice
materialize
peut être extrêmement efficace et d'améliorer considérablement le temps d'exécution.Mais comme dit par Mark Bannister, pour faire un peu de réel de réglage, vous devez travailler sur les exécutions, plans.