INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q082 — Pourquoi un index B-tree est-il peu utile pour certaines requêtes à très faible sélectivité ?
Je vous remercie pour cette question, qui touche au cœur du fonctionnement des index en base de données. ## Réponse Un index B-tree est peu utile pour les requêtes à très faible sélectivité, c'est-à-dire celles qui sélectionnent une très grande proportion des lignes de la table (par exemple 50 %, 80 % ou plus), pour une raison essentielle : le coût d'accès par ligne indexée dépasse celui d'un balayage séquentiel. ## Justification Le B-tree est conçu pour l'accès ponctuel ou par plage étroite. Son avantage vient de ce qu'il permet de ne lire que les pages de données strictement nécessaires. Or, ce bénéfice repose sur la sélectivité : plus la fraction de lignes retournées est faible, plus l'économie de lecture est grande. Lorsque la sélectivité devient très faible, deux mécanismes se retournent contre l'index. D'abord, le coût des lectures aléatoires. Chaque ligne satisfaisant le prédicat est localisée via l'index, puis la page de données correspondante est lue. Ces lectures se font en accès aléatoire, bien plus coûteux que la lecture séquentielle. Quand on touche une grande fraction des lignes, on finit par lire presque toutes les pages de la table, mais en ordre dispersé, ce qui est plus lent qu'un simple balayage linéaire. Ensuite, le coût de traversée de l'index lui-même. L'optimiseur doit parcourir une grande portion de l'arbre pour collecter toutes les entrées correspondantes, puis effectuer les retours à la table. Ce surcoût s'ajoute sans apporter de gain, puisque de toute façon presque toute la table sera lue. Enfin, le seuil de basculement. Les optimiseurs estiment le coût des deux stratégies et choisissent le balayage séquentiel dès que la fraction estimée dépasse un seuil, souvent de l'ordre de 5 à 10 % des lignes (ce seuil varie selon le moteur, la taille des pages et la présence d'un balayage parallèle). Au-delà, l'index devient contre-productif. ## Cas particuliers à nuancer Il faut toutefois préciser deux exceptions où un B-tree peut rester utile même à faible sélectivité. L'index couvrant. Si toutes les colonnes nécessaires à la requête sont dans l'index, on évite le retour à la table : l'index seul suffit, et le coût des lectures aléatoires disparaît. L'index peut alors rester compétitif. L'ordre de tri. Si la requête exige un tri sur la colonne indexée, le B-tree fournit les lignes déjà triées, ce qui peut économiser une opération de tri coûteuse, même pour une sélectivité faible. ## Confiance Je situe ma confiance à 90 %. La justification repose sur des principes bien établis de l'optimisation des bases de données relationnelles (coût comparé des accès séquentiels et aléatoires, seuil de basculement de l'optimiseur). La valeur précise du seuil de sélectivité varie selon les moteurs et n'est pas une constante universelle, ce qui explique que je ne puisse pas donner un chiffre exact ; c'est pourquoi je n'ai pas avancé de valeur absolue. Les deux exceptions citées (index couvrant et tri) sont des cas standard documentés. En résumé, l'index B-tree brille par sa précision chirurgicale ; dès que la requête embrasse une trop grande part de la table, cette précision devient un luxe coûteux, et le balayage séquentiel reprend la main.
Resultat fige a la premiere execution, directement depuis le service public LANXAS White, sans intervention manuelle. Cette page est permanente et peut etre re-consultee pour verification.