Question

Lorsque vous travaillez avec des tables dans Oracle, comment savoir si vous configurez un bon index par rapport à un mauvais index?

Était-ce utile?

La solution

Cela dépend de ce que vous entendez par «bon» et «mauvais». En gros, vous devez comprendre que chaque index que vous ajoutez augmentera les performances de toute recherche effectuée dans cette colonne (ajouter un index à la colonne "nom de famille" d'une table de personnes augmentera les performances des requêtes contenant "où nom de famille ="). ) mais diminue les performances en écriture sur l’ensemble de la table.

La raison en est que lorsque vous ajoutez ou mettez à jour une ligne, celle-ci doit ajouter ou mettre à jour la table elle-même et tous les index dont cette ligne est membre. Donc, si vous avez cinq index sur une table, chaque addition doit écrire à six emplacements - cinq index et la table - et une mise à jour peut toucher jusqu'à six emplacements dans le pire des cas.

La création d'index est un acte d'équilibrage entre vitesse de requête et vitesse d'écriture. Dans certains cas, comme un magasin de données chargé uniquement de données une fois par semaine dans un travail nocturne, mais interrogé des milliers de fois par jour, il est très judicieux de surcharger des index et d'accélérer au maximum les requêtes. Toutefois, dans le cas des systèmes de traitement des transactions en ligne, vous souhaitez essayer de trouver un équilibre.

Bref, ajoutez des index aux colonnes très utilisées dans certaines requêtes, mais évitez d’en ajouter trop et ajoutez d’abord les colonnes les plus utilisées.

Après cela, il suffit de tester la charge pour voir comment les performances réagissent dans les conditions de production, et de peaufiner les réglages pour trouver un équilibre acceptable.

Autres conseils

Les champs divers, hautement spécifiques ou uniques constituent de bons index. Tels que les dates et les horodatages, les numéros incrémentants uniques (couramment utilisés comme clés primaires), les noms des personnes, les numéros de plaques d'immatriculation, etc.

Un contre-exemple serait le genre - il n'y a que deux valeurs communes, donc l'index n'aide pas vraiment à réduire le nombre de lignes à analyser.

Les chaînes de forme libre descriptives de longueur complète génèrent de mauvais index car celui qui effectue la requête connaît rarement la valeur exacte de la chaîne.

Les données ordonnées linéairement (telles que les horodatages ou les dates) sont couramment utilisées en tant qu'index clusterisé, ce qui oblige les lignes à être stockées dans l'ordre des index et permet un accès en ordre, ce qui accélère considérablement les requêtes d'intervalle (par exemple, "donnez-moi tout". les commandes passées entre octobre et décembre '). Dans ce cas, le moteur de base de données peut simplement rechercher le premier enregistrement spécifié par la plage et commencer à lire de manière séquentielle jusqu'à atteindre le dernier.

Voici un excellent article sur SQL Server: http://www.sql-server-performance.com/tips/optimizing_indexes_general_peneral_p1. aspx

Bien que les mécanismes ne fonctionnent pas sur Oracle, les astuces sont très utiles (moins la chose sur les index clusterisés, qui ne fonctionnent pas exactement de la même manière dans Oracle).

@ Vache infâme - vous devez penser aux clés primaires et non aux index.

@Xenph Yan - Quelque chose d’autre n’a pas été évoqué, c’est de choisir le type de type d’index à créer. Certaines bases de données ne vous donnent pas vraiment le choix, mais certaines ont une grande variété d’index possibles. Les B-trees sont les valeurs par défaut mais ne sont pas toujours le meilleur type d’index. Le choix de la bonne structure dépend du type d'utilisation que vous prévoyez avoir. Quels types de requêtes avez-vous le plus besoin d'assistance? Êtes-vous dans un environnement principalement en lecture ou en écriture? Vos écritures sont-elles dominées par les mises à jour ou les annexes? Etc, etc.

Vous trouverez une description des différents types d’index et de leurs avantages et inconvénients à l’adresse suivante: http://20bits.com/2008/05/13/interview-questions-database-indexes/ .

Quelques règles de base si vous essayez d’améliorer une requête particulière.

Pour une table particulière (où Oracle devrait commencer, selon vous), essayez d’indexer chacune des colonnes utilisées dans la clause WHERE. Placez les colonnes avec l’égalité en premier, suivies des colonnes avec une plage ou similaire.

Par exemple:

WHERE CompanyCode = ? AND Amount BETWEEN 100 AND 200

Si les colonnes ont une très grande taille (par exemple, vous stockez du XML ou quelque chose de ce genre), il vaut peut-être mieux les laisser en dehors de l'index. Cela réduira l'index à analyser, en supposant que vous deviez quand même accéder à la ligne du tableau pour satisfaire la liste de sélection.

Sinon, si toutes les valeurs des clauses SELECT et WHERE se trouvent dans l'index, Oracle n'aura pas besoin d'accéder à la ligne du tableau. Il est donc parfois utile de placer les valeurs sélectionnées en dernier dans l’index et d’éviter tout accès à la table.

Vous pourriez écrire un livre sur les meilleures façons d’indexer - cherchez l’auteur Jonathan Lewis.

Un bon index est une chose sur laquelle vous pouvez compter pour être unique pour une ligne de tableau spécifique.

Un schéma d'index couramment utilisé est l'utilisation de nombres qui s'incrémentent de 1 pour chaque ligne du tableau. Chaque ligne finira par avoir un index numérique différent.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top