Dois-je créer des index sur des clés étrangères?

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 de la requête, de créer un index séparé sur A. B_ID.

Si vous supprimez des lignes dans B, vous voulez absolument 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 comme Eh bien, mais ceux-ci sont diminués dans les versions plus récentes D'Oracle).

Juste pour plus d'informations: Oracle ne crée pas un 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 toute la table enfant.

Un cas où je choisis généralement Pas pour ajouter un index est l'endroit où le FK est à 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 sur la table parent ne sont jamais effectuées directement par l'application. Cependant, si l'ajout d'un index sur la colonne donne des avantages aux requêtes importantes dans l'application, alors l'index sera toujours un bon idée.

SQL Server n'a jamais mis automatiquement des index sur des colonnes de clés étrangères-consultez L'excellent article de blog de Kim Tripp sur le fond et l'histoire de ce mythe urbain.

C'est généralement une bonne idée d'indexer vos colonnes de clés étrangères, cependant - alors oui, je recommanderais de m'assurer que chaque colonne FK est sauvegardée par un index; pas nécessairement sur cette seule colonne - peut-être qu'il peut être logique 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 performance, 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 Moteur (Fichiers Microsoft Access) Firebird MySQL

À COUP SÛR

Serveur SQL Oracle

NE FAIT PAS

Comme pour tout ce qui concerne la performance, cela dépend de nombreux facteurs et il n'y a pas de balle silve, par exemple dans un environnement d'activité très élevé, la maintenance d'un index peut être inacceptable.

Le plus saillant 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 une analyse de table.