Dire que j'ai deux tables, a code> et
b code>:
FROM a
JOIN b on a.fk = b.pk
3 Réponses :
a.fk code> est configuré pour être une clé étrangère sur b.pk code> - b.pk code> est indexé li>
- Il n'y a pas de relation entre les tables -
b.pk code> est indexé li>
-
a.fk code> est configuré pour être une clé étrangère sur b.pk - b.pk code> n'est pas indexé li>
- Il n'y a pas de relation entre les tables -
b.pk code> n'est pas indexé li>
ol>
Merci! Très utile. Une idée de la grande différence de performance entre 1 et 2 (dans votre classement) serait?
Négligible si du tout, il y aurait une différence.
Le lien est cassé.
Les différend de performance seraient plus grandes entre les versions indexées et non indexées, cependant, que ce soit plus rapide ou plus lente dépendrait de savoir s'il s'agissait d'une sélection ou d'un insert. Avoir des index et des contraintes de clés étrangères ralentissez les inserts, mais la vitesse sélectionnée sélectionne (l'index) ou rendre les données plus fiables (la FK). Étant donné que la plupart des inserts ne sont généralement pas ralentis (sauf si vous faites de gros inserts en vrac), il est généralement de votre mieux l'intérêt d'avoir le FK et l'index. p>
Je vais savoir la réponse de Lieven. Juste pour répondre à votre question de bonus de la quantité de performance que vous obtenez de créer un index, la réponse est «qui dépend». P>
Si une ou les deux tables sont petites et ce sont les deux seules tables de la requête, le gain de performance pourrait être petit à zéro. Lorsque le nombre d'enregistrements est petit, il est parfois plus rapide de simplement lire tous les enregistrements plutôt que d'utiliser l'index de toute façon. Le moteur de base de données devrait être suffisamment intelligent pour comprendre cela - c'est ce que "optimisation de la requête est tout à propos de". P>
De même, si vous avez d'autres tables impliquées et d'autres critères de sélection, le moteur DB peut décider de ne pas utiliser cet index et qu'une autre façon de trouver les enregistrements est plus rapide. P>
À l'autre extrême, si vous avez deux très grandes tables, la création d'un index sur le champ utilisé pour les rejoindre peut couper le temps d'exécution de 99% ou plus. P>
C'est pourquoi c'est une bonne idée d'apprendre à lire les plans d'explication sur votre moteur DB. Si une requête prend beaucoup de temps, courez le plan d'explication et voyez ce que cela fait. Souvent, la création d'un bon index peut améliorer considérablement une requête. P>