2016-03-31 1 views
0

J'ai un certain nombre de tables, environ quatre, que je souhaite joindre ensemble. Pour faire mon propre code et lisible (pour moi), je souhaite me joindre à la fois, puis filtrer à la fin:Joindre plusieurs tables: où filtrer efficacement

SELECT f1, f2, ..., fn 
FROM t1 INNER JOIN t2 ON t1.field = t2.field 
     INNER JOIN t3 ON t2.field = t3.field 
     INNER JOIN t4 ON t3.field = t4.field 
WHERE // filters here 

Mais je soupçonne que placer chaque table dans les sous-requêtes et le filtrage dans chaque champ serait la performance meilleur.

SELECT f1, f2, ..., fn 
FROM (SELECT t1_f1, t1_f2, ..., t1_fi FROM t1 WHERE // filter here) AS a 
    INNER JOIN 
    (SELECT t2_f1, t2_f2, ..., t2_fj FROM t2 WHERE // filter here) AS b 
    ON // and so on 

Veuillez aviser ce qui conduirait à de meilleures performances et/ou si mon intuition est correcte. Je suis prêt à sacrifier la performance à la lisibilité.

Si le filtrage dans chaque sous-requête est effectivement plus efficace, l'architecture de la plate-forme de base de données fera-t-elle une différence ou est-ce vrai pour toutes les versions de RDBMS SQL? J'utilise SQL Server et PostgreSQL.

+6

Écrire un code lisible, l'optimiseur est censé prendre en charge l'ordre de filtrage. – jarlh

+2

vous pouvez également utiliser le filtre directement dans la condition de jointure: 'FROM t1 JOIN t2 ON t1.field = t2.field ET t2.column3> 42'. Mais les trois alternatives généreront très probablement le même plan d'exécution. Mais le ** seul ** moyen de vérifier cela, est de regarder les plans d'exécution (dans les deux produits) –

+0

Pour PosgresSQL ou MySQL, utilisez EXPLAIN pour obtenir plus d'informations sur la façon dont votre requête sera exécutée. SQL Server dispose d'un outil graphique pour afficher le plan d'exécution. Pour optimiser le démarrage SQL depuis la sortie du plan d'exécution –

Répondre

2

L'optimiseur de requêtes tentera toujours de trouver le plan optimal à partir de votre SQL. Vous devriez vous concentrer davantage sur l'écriture de code lisible et maintenable, puis, en analysant le plan d'exécution, trouver les parties inefficaces de votre requête (et plus probablement) les parties inefficaces de votre base de données et de votre conception d'indexation.

Déplacer votre filtrage de la clause where vers la clause de jointure sans analyse significative risque d'être un gaspillage d'efforts.

0

La jointure fonctionnera toujours mieux si vous avez indexé correctement.

+0

Cela ne répond pas vraiment à la question. – MikeTheLiar

1

Votre première approche sera toujours meilleure car le moteur SQL évaluera d'abord les conditions, puis effectuera les jointures. Ainsi, tout en évaluant la clause where, il filtrera les enregistrements si les conditions sont disponibles.

SELECT f1, f2, ..., fn 
FROM t1 INNER JOIN t2 ON t1.field = t2.field 
    INNER JOIN t3 ON t2.field = t3.field 
    INNER JOIN t4 ON t3.field = t4.field 
WHERE // filters here 
+1

Ce n'est tout simplement pas vrai (du moins pas "en général" comme vous le prétendez). Je ne serais pas surpris du tout si les deux alternatives conduisent aux mêmes plans d'exécution. –