Quand créer des index ?

**zaineb.z** · 28/04/2008, 18h19

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** · 28/04/2008, 23h00

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

**frp31** · 29/04/2008, 08h37

surtout eviter d'indexer des colonnes pouvant contenir des doublons

**pifor** · 29/04/2008, 08h41

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** · 29/04/2008, 10h20

type d'index

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

**13thFloor** · 29/04/2008, 10h30

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** · 29/04/2008, 10h40

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** · 29/04/2008, 10h45

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

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

**zaineb.z** · 29/04/2008, 11h27

Merci

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

**orafrance** · 29/04/2008, 14h49

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** · 29/04/2008, 17h17

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** · 30/04/2008, 10h21

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** · 30/04/2008, 10h39

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

**orafrance** · 30/04/2008, 13h46

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

**zaineb.z** · 30/04/2008, 14h10

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** · 30/04/2008, 14h36

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** · 30/04/2008, 15h33

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** · 30/04/2008, 15h57

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** · 30/04/2008, 15h58

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.