J'ai une table Aet une table B. Aa une clé étrangère Bsur la Bclé primaire », B_ID.
Pour une raison quelconque (je sais qu'il y a des raisons légitimes), il n'utilise pas d'index lorsque je joins ces deux tables sur la clé.
Dois-je créer séparément un index sur A.B_IDou l'existence d'une clé étrangère doit-elle le fournir?
Réponses:
La contrainte de clé étrangère seule ne fournit pas l'index sur Oracle - il faut (et devrait) être créé.
oraclemais ce n'est pas immédiatement évident lorsque vous arrivez ici à partir d'une recherche Google.
La création d'une clé étrangère ne crée pas automatiquement un index sur A.B_ID. Il serait donc généralement logique du point de vue des performances des requêtes de créer un index distinct sur A.B_ID.
Si jamais vous supprimez des lignes dans B, vous voulez certainement que A.B_ID soit indexé. Sinon, Oracle devra effectuer une analyse complète de la table sur A chaque fois que vous supprimez une ligne de B pour vous assurer qu'il n'y a pas d'enregistrements orphelins (selon la version d'Oracle, il peut y avoir des implications de verrouillage supplémentaires, mais celles-ci sont diminuées dans les versions Oracle plus récentes).
B_ID.
Juste pour plus d'informations: Oracle ne crée pas d'index automatiquement (comme il le fait pour les contraintes uniques) car (a) il n'est pas nécessaire d'appliquer la contrainte, et (b) dans certains cas, vous n'en avez pas besoin.
La plupart du temps, cependant, vous voudrez créer un index (en fait, dans Oracle Apex, il y a un rapport de "clés étrangères non indexées").
Chaque fois que l'application doit pouvoir supprimer une ligne dans la table parent, ou mettre à jour la valeur PK (qui est plus rare), le DML souffrira si aucun index n'existe, car il devra verrouiller la table enfant entière.
Un cas où je choisis généralement de ne pas ajouter d'index est celui où le FK se trouve dans une table de "données statiques" qui définit le domaine d'une colonne (par exemple une table de codes d'état), où les mises à jour et les suppressions de la table parent ne sont jamais effectuées directement par l'application. Cependant, si l'ajout d'un index sur la colonne présente des avantages pour des requêtes importantes dans l'application, l'index sera toujours une bonne idée.
SQL Server n'a jamais mis automatiquement d'index sur des colonnes de clés étrangères - consultez l' excellent article de blog de Kim Tripp sur le contexte et l'histoire de ce mythe urbain.
Cependant, c'est généralement une bonne idée d'indexer vos colonnes de clé étrangère - donc oui, je recommanderais de vous assurer que chaque colonne FK est sauvegardée par un index; pas nécessairement sur cette seule colonne - peut-être qu'il peut être judicieux de créer un index sur deux ou trois colonnes avec la colonne FK comme première. Dépend de votre scénario et de vos données.
Pour des raisons de performances, un index doit être créé. Est utilisé dans les opérations de suppression sur la table primaire (pour vérifier que l'enregistrement que vous supprimez n'est pas utilisé) et dans les jointures qui impliquent généralement une clé étrangère. Seules quelques tables (je ne les crée pas dans les journaux) pourraient ne pas avoir besoin de l'index, mais probablement, dans ce cas, vous n'avez probablement pas besoin de la contrainte de clé étrangère.
MAIS
Certaines bases de données créent déjà automatiquement des index sur des clés étrangères. Jet Engine (fichiers Microsoft Access) Firebird MySQL
POUR SÛR
Oracle SQL Server
NE FAIT PAS
Comme pour tout ce qui concerne les performances, cela dépend de nombreux facteurs et il n'y a pas de balle silencieuse, par exemple dans un environnement très actif, le maintien d'un index peut être inacceptable.
Le plus important ici semble être la sélectivité: si les valeurs de l'index sont fortement dupliquées, cela peut donner de meilleures performances pour supprimer l'index (si possible) et permettre un balayage de table.
Les contraintes UNIQUE, PRIMARY KEY et FOREIGN KEY génèrent des index qui appliquent ou «rétrogradent» la contrainte (et sont parfois appelés index de sauvegarde). Les contraintes PRIMARY KEY génèrent des index uniques. Les contraintes FOREIGN KEY génèrent des index non uniques. Les contraintes UNIQUE génèrent des index uniques si toutes les colonnes ne sont pas Nullables et génèrent des index non uniques si une ou plusieurs colonnes sont Nullables. Par conséquent, si une colonne ou un ensemble de colonnes a une contrainte UNIQUE, PRIMARY KEY ou FOREIGN KEY, vous n'avez pas besoin de créer un index sur ces colonnes pour les performances.