Quand créer des index ? [Résolu]

[zaineb.z]

Bonsoir,
quand est ce est jugé necessaire de créer des index ?
parce que là , j'ai une table susceptible de contenir des millions de lignes .
déjà j'ai lu quelques part que oracle crée automatiquement un index sur le key de la table , dans ce cas dois je en créer un autre sur une clé étrangère de la table ?

[messalux]

pour les colonne utilisés dans des jointures, clauses where...
il faut aussi se poser la question de quel type d'index mettre??

[frp31]

surtout eviter d'indexer des colonnes pouvant contenir des doublons

[pifor]

Envoyé par zaineb.z

Bonsoir,
dans ce cas dois je en créer un autre sur une clé étrangère de la table ?

En général il est recommandé de créer des index sur les clés étrangères au moins pour des raisons de concurrence d'accès.

Envoyé par frp31

surtout eviter d'indexer des colonnes pouvant contenir des doublons

Pourquoi une règle aussi générale ?

[zaineb.z]

type d'index je croyais qu'il y a qu'un seul type d'index

[13thFloor]

Envoyé par zaineb.z

type d'index je croyais qu'il y a un seul type d'index

btree (par défaut), bitmap, reverse, descending, fbi... tu as le choix.

En réponse à ta question initiale, je dirai :
- quand le coût de recherche d'informations est meilleur (moins de blocs à parcourir que pour lire totalement une table)
- pour garantir l'intégrité des données (index unique ou primaire)

[zaineb.z]

Donc , pour remédier à mon problème ( recherche plus rapide ... ) je dois créer un index sur les clés étrangères ou non? vous me conseillez quel type d'index ?
et merci tous de m'avoir repondue

[maguie]

je te conseille de lire ce cours il parle des diiférents types d'index:

http://duongkhang.free.fr/Wika/wikka...OptimisationBD

[zaineb.z]

Merci
j'hesite entre le type bitmap et b-tree , lequel entre les deux dois je opter pour ?

[orafrance]

bitmap n'est à utiliser que dans des cas exceptionnelles : très forte volumétrie, valeurs de colonne fixe (sexe, oui/non, etc...) et peu de mise à jour de l'index.

Voici des articles intéressant sur l'optimisation :
OPTIMISATION des SGBDR et du SQL
Intéret des indexes par l'exemple et Optimiser SQL Server (sous SQL Server mais c'est la méthode qui est importante)

[zaineb.z]

Merci j'ai lu le cours, c'est très intéressant sauf que... je n'arrive pas à me décider.
j'ai même fait une recherche dans le forum , c'est très ambigu ce que j'ai trouvé
ce que j'ai compris c'est que si j'ajoute un index à ma table , je dois le faire sur les clés étrangères et cela,d'après ce que j'ai lu, n'est pas toujours très "optimisant" lors des recherches ( select , insert en lot )
je ne sais plus quoi faire....

[orafrance]

Bah il y a un moment où la prévision de l'avenir a ses limites... donc sauf si est doué de don de voyance, je ne peux que t'encourager à tester les indexes que tu penses être intéressant. Enfin, sur une FK c'est rarement inutile

[zaineb.z]

D4acc , donc un b tree sur les pk , à chaque pk un index c'est bien cela ?

[orafrance]

oui, JAMAIS de bitmap sur une PK. Et PK = contrainte unique + index

[zaineb.z]

dans ma table , il y a un seul pk , j'ai lu quelques part que oracle crée un index automatiquement avec le pk ,
donc , si je veux réduire le temps d'exécution des requêtes , dois je créer un index sur les champs les plus sollicités dans mes requêtes ?

[13thFloor]

Envoyé par zaineb.z

dans ma table , il y a un seul pk , j'ai lu quelques part que oracle crée un index automatiquement avec le pk ,
donc , si je veux réduire le temps d'exécution des requêtes , dois je créer un index sur les champs les plus sollicités dans mes requêtes ?

Oui et non.
Oui si le parcours par index est moins couteux que lire toute la table.
Oui si la proportion de données à ramener est faible (moins de 15%).
Dans le doute, un histogramme sur les colonnes indexées aidera l'optimiseur à choisir entre un parcours par index ou un parcours de la table.
Oui si le nombre de blocs occupés par la table est significatif.

Attention : trop d'index nuit aux perfs lors des mises à jours.
Attention (bis) aux paramètres optimizer_index_cost_adj et db_file_multiblock_read_count qui ont un impact sur la prise en compte des index.

[orafrance]

Envoyé par 13thFloor

Attention (bis) aux paramètres optimizer_index_cost_adj et db_file_multiblock_read_count qui ont un impact sur la prise en compte des index.

NON ! Je voudrais qu'on arrête de parler de ces paramètres qui sont extrêmement délicat à utiliser et en général, quand on en est à toucher à ça, c'est qu'il y a un autre problème.

Il vaut mieux avant toute chose se concentrer sur les stats.

Pour répondre à zaineb.z, en général on indexe les colonnes filtrantes (dans le WHERE) en tenant compte de la sélectivité des données. Les liens que j'ai donné expliquent tout ça.

[13thFloor]

Envoyé par orafrance

NON ! Je voudrais qu'on arrête de parler de ces paramètres qui sont extrêmement délicat à utiliser et en général, quand on en est à toucher à ça, c'est qu'il y a un autre problème.

C'est juste une mise en garde concernant les possibilités de favoriser ou non l'utilisation des index, pas une préconisation.
Juste pour lui indiquer que les stats ne sont pas les seules éléments qui déterminent si un index est utilisé ou non.

[orafrance]

Sauf qu'il n'y a pas à y faire attention... en plus, on a à faire visiblement à un débutant et c'est dommage de l'embrouiller avec des paramètres qu'on ne doit pas toucher.

[zaineb.z]

merci de m'avoir repondu ,
orafrance , tu as raison , quand j'ai lu

optimizer_index_cost_adj et db_file_multiblock_read_count

j'ai
merci à tous encore et bonne soirée