J'ai une table A et une table B . A a une clé étrangère vers B en B de la clé primaire, B_ID .
Pour une raison quelconque (je sais qu'il existe 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_ID ou l'existence d'une clé étrangère doit-elle le fournir ?
Sur certaines bases de données, la création d'une contrainte de clé étrangère crée également un index... par exemple Jet Engine (fichiers MSAccess, Firebird et MySQL).
Cette réponse n'a aucun sens si elle ne fait pas explicitement référence à une implémentation particulière de la base de données. Bien sûr, la question est étiquetée oracle mais ce n'est pas immédiatement évident quand on atterrit ici après une recherche sur Google.
Je peux confirmer que PostgreSQL - du moins au moment de la rédaction de cet article - ne le fait pas automatiquement.
La création d'une clé étrangère ne crée pas automatiquement un index sur A.B_ID. Ainsi, du point de vue de la performance des requêtes, il serait généralement judicieux 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 un balayage complet de la table sur A chaque fois que vous supprimez une ligne de B pour s'assurer qu'il n'y a pas d'enregistrements orphelins (selon la version d'Oracle, il peut également y avoir des implications supplémentaires en matière de verrouillage, mais celles-ci sont réduites dans les versions plus récentes d'Oracle).
Qu'en est-il des colonnes PFK ? Par exemple, si j'ai une table intermédiaire pour une relation many-to-many, dois-je créer un index pour les deux colonnes PFK de cette table ?
Pour plus d'informations : Oracle ne crée pas automatiquement un index (comme il le fait pour les contraintes uniques) parce que (a) il n'est pas nécessaire pour appliquer la contrainte, et (b) dans certains cas, vous n'en avez pas besoin.
Le plus Dans la plupart des cas, cependant, vous voudrez créer un index (en fait, dans Oracle Apex, il existe un rapport sur les "clés étrangères non indexées").
Lorsque l'application doit être en mesure de supprimer une ligne dans la table parent, ou de mettre à jour la valeur PK (ce qui est plus rare), le DML souffrira de l'absence d'index, car il devra verrouiller l'ensemble de la table enfant.
Un cas où je choisis habituellement no pour ajouter un index est lorsque 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 parente ne sont jamais faites directement par l'application. Cependant, si l'ajout d'un index sur la colonne apporte des avantages à des requêtes importantes dans l'application, alors l'index sera toujours une bonne idée.
SQL Server n'a jamais placé automatiquement des index sur les colonnes de clés étrangères - consultez l'article de Kim Tripp intitulé excellent blog post sur le contexte et l'histoire de ce mythe urbain.
Toutefois, il est généralement judicieux d'indexer vos colonnes de clés étrangères. Je vous recommande donc de vous assurer que chaque colonne de clé étrangère est sauvegardée par un index, mais pas nécessairement sur cette seule colonne. Tout dépend de votre scénario et de vos données.
Comme pour tout ce qui concerne les performances, celles-ci dépendent de nombreux facteurs et il n'y a pas de solution miracle. Par exemple, dans un environnement à très forte activité, la maintenance d'un index peut être inacceptable.
La sélectivité semble être le critère le plus important : si les valeurs de l'index sont fortement dupliquées, il peut être plus performant de supprimer l'index (si possible) et de permettre un balayage de la table.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
