Currenlty J'utilise beaucoup de jointures internes (environ 7) dans mon sp, a-t-il un impact sur la perfomance sp. la jointure externe gauche donne une meilleure performance que la jointure interne. Encore une chose si je joins deux tables a et b qui ont l'id de la colonne et id1, les deux r non nulles. Je suppose ici que je peux aller pour la jointure intérieure comme ces colonnes sont indexées.Y a-t-il un problème de performance avec Inner Join?
Tout d'abord, ces deux sont destinés à servir un but différent. La comparaison peut donc ne pas être valable dans tous les cas.
Vous pouvez lire plus ici.
Les jointures externes sont plus chers que les jointures internes. Ce que je vais dire va être controversé pour beaucoup. Si vous réglez la base de données correctement et si vous ne faites rien d'idiot et si vous utilisez un RDBMS professionnel, alors 7 jointures internes ne devraient pas poser de problème.
Qu'est-ce que je veux dire par le réglage de base de données? Il y a beaucoup de réglages de base de données, mais la chose la plus évidente à vérifier est de s'assurer que vous joignez toujours les colonnes qui sont indexées.
Qu'est-ce que je veux dire par goofy? N'utilisez pas l'opérateur OR dans votre condition de jointure. Essayez de garder vos jointures sur une seule comparaison comme une clé étrangère dans un tableau égal à la clé primaire dans l'autre table. Essayez de garder tous vos champs clés comme des entiers.
Si vous rencontrez des problèmes de performances, veillez à étudier le plan d'exécution de la requête incriminée. Par exemple, vous risquez de rencontrer des problèmes en rejoignant des tables très volumineuses, si grandes que même une analyse d'index est trop lente. Vous devrez peut-être dénormaliser et fournir un filtrage supplémentaire pour réduire les temps d'analyse. N'essayez pas d'anticiper cela. La dénormalisation est à peine faite à peine et seulement après avoir rencontré des situations de performance dans le monde réel.
Où était la partie controversée, encore une fois? Le nombre de jointures? Je pense que cela dépend seulement des tables qui sont jointes. Aussi, de bons conseils sur les clauses "OR". Ils sont trompeusement chers, en particulier dans SQL Server. – Eric
J'ai déjà travaillé avec des développeurs qui croyaient que vous ne devriez pas dépasser trois jointures pour des raisons de performances. J'aurais été d'accord avec cela dans les années 1980, mais pas aujourd'hui. – Glenn
JOIN est utilisé dans un but spécifique & pas pour la performance. LEFT OUTER JOIN est utilisé pour inclure des enregistrements pour lesquels il n'y a aucun enregistrement correspondant dans le tableau de droite. INNER JOIN sélectionne les enregistrements correspondants en fonction de certains critères, dans les deux tableaux.
Ce petit mot sur LEFT OUTER JOIN a été super utile pour moi. Passer d'un INNER JOIN à un OUTER JOIN a coupé ma requête de 16 secondes à 50 ms. Je ne cherchais pas sur les colonnes de la table jointe pour pouvoir les joindre après coup. –
Pour faire suite à ce que Glenn said, si vous vous joignez à la "substance goofy", extraire cela dans les tableaux temporaires à l'avance peut également aider. Dans une base de données sur laquelle j'ai travaillé par le passé, la jointure était sur une clé partielle (les tables contenaient des clés composites, c'est-à-dire une clé primaire avec plusieurs colonnes) et un filtrage supplémentaire se produisait dans la clause where. Le filtrage dans la clause where a pris l'ensemble des lignes à regarder de plusieurs milliards jusqu'à plusieurs milliers d'un côté de la jointure. Rejoindre une table de plusieurs milliers de lignes était beaucoup plus facile que sur plusieurs milliards. Le temps de requête est passé de 20 minutes à 7 secondes si je me souviens bien.
Notez également que nous avions aussi des sous-requêtes et des UDF (fonctions définies par l'utilisateur), ce qui a probablement ajouté à la folie.
Les jointures à gauche donnent des résultats différents des jointures internes et ne doivent donc pas être utilisées comme substitut. Plus que probablement, c'est l'indexation dont vous avez besoin. Alors que les index sont créés automatiquement lorsque vous définissez une clé primaire, ils ne sont pas créés lorsque vous définissez une clé étrangère. Vous aurez donc besoin d'indexer toutes les clés qui se trouvent dans vos jointures si vous ne l'avez pas déjà fait.
Vérifiez également votre plan d'exécution pour voir où le problème est.
Pour des conseils plus spécifiques sur les moyens d'améliorer les performances de votre requête, vous devez nous le montrer.
La raison pour laquelle les jointures sont généralement coûteuses est que la jointure peut entraîner un nombre de tuples supérieur à la taille de l'une ou l'autre table. Cependant, parfois, les attributs de jointure dans une table déterminent fonctionnellement un n-uplet unique dans une autre table. dans ce cas, rejoindre peut être très bon marché (mais vous devrez indexer sur ces attributs).
Cette opération est peu coûteuse, quel que soit le nombre de jointures que vous avez effectuées. Il s'agit plutôt d'un problème de dépendances de données et de données.
Puisque vous vous connectez sur 2 clés, où il semble que la même clé est utilisée pour les deux tables, cela devrait être une opération peu coûteuse, quel que soit le type de jointure que vous utilisez.
avez-vous des index sur les colonnes utilisées pour la condition de jointure (ainsi que toute colonne utilisée pour une autre condition, comme dans la clause where)? cela peut vraiment aider. En général, j'ai entendu dire que l'intérieur est meilleur pour la performance que la gauche - mais ce qui doit être utilisé dépend de ce que vous voulez obtenir ^^ –