Pour plus de lisibilité, j'ai restructuré la requête... en commençant par le niveau supérieur apparent étant Table1, qui est ensuite lié à Table3, puis table3 est lié à table2. Beaucoup plus facile à suivre si vous suivez la chaîne des relations.
Maintenant, pour répondre à votre question. Vous obtenez un grand nombre à la suite d'un produit cartésien. Pour chaque enregistrement dans Table1 qui correspond à Table3, vous aurez X * Y. Ensuite, pour chaque correspondance entre table3 et Table2 aura le même impact... Y * Z... Donc, votre résultat pour un seul ID possible dans la table 1 peut avoir X * Y * Z enregistrements.
Ceci est basé sur le fait de ne pas savoir comment est la normalisation ou le contenu de vos tables... si la clé est une clé PRIMAIRE ou non...
Ex:
Table 1
DiffKey Other Val
1 X
1 Y
1 Z
Table 3
DiffKey Key Key2 Tbl3 Other
1 2 6 V
1 2 6 X
1 2 6 Y
1 2 6 Z
Table 2
Key Key2 Other Val
2 6 a
2 6 b
2 6 c
2 6 d
2 6 e
Ainsi, la jonction de la table 1 à la table 3 entraînera (dans ce scénario) 12 enregistrements (chacun en 1 joint à chacun en 3). Ensuite, tout cela multiplié par chaque enregistrement correspondant dans la table 2 (5 enregistrements)... un total de 60 ( 3 tbl1 * 4 tbl3 * 5 tbl2 ) serait renvoyé.
Alors, maintenant, prenez cela et développez en fonction de vos milliers d'enregistrements et vous voyez comment une structure foirée peut étouffer une vache (pour ainsi dire) et tuer les performances.
SELECT
COUNT(*)
FROM
Table1
INNER JOIN Table3
ON Table1.DifferentKey = Table3.DifferentKey
INNER JOIN Table2
ON Table3.Key =Table2.Key
AND Table3.Key2 = Table2.Key2
