[Technique] Intérêt des index

[ddams]

Je vous explique la situation,

je dispose d'un base de données dans la quelle j'ai créé une table qui me sert de table de travail.

Cette table étant remplie dynamiquement, est-il judicieux d'y créé des index ?

Les indexs sont faits pour accélérer le traitement, mais comme ma table se rempli dynamiquement, la création des tables d'indexs prend aussi du temps !!! bref je suis devant un dilème et mes jeux d'essais ne m'ont pas apporter la solution.

merci d'avance

@+ddams

[hachesse]

salut

un index sert a accelerer les recherche dans un table
c'est donc a toi de voir si tu a besoin d'un access rapide a certaine donnée ou non

[laffreuxthomas]

un index accélère la recherche (requêtes SELECT) mais ralenti les mises à jour (INSERT, UPDATE, DELETE).

A voir donc...

Ca vaut souvent le coup de poser des index sur les clefs étrangères afin d'accélérer les jointures.

Thomas

[Sylvain James]

En général le temps gagné lors des SELECT est largement visible alors que le temps perdu sur des requêtes de mise à jour ne se ressent pas à moins que ce soit des gros volumes d'opérations à chaque fois.
Il est tout à fait judicieux de créer des index.

Sylvain

[ddams]

merci pour vos réponses...

@+ddams

[fadace]

Petit ajout : un index dit cluster sert aussi parfois à trier les données physiquement dans la table. Ca a un avantage sur la ventilation des données dans la table, et donc sur diverses partitins, segments, etc. En clair, ça peut améliorer les accès concurrents et évitant certaines contentions en fin de pages.

De plus, c'est un des moyens pour s'assurer l'unicité de clés.

[la drogue c'est mal]

tres franchement je vois pas en quoi le fait de creer un index ralenti tes insertion, ce n'est qu'un champ de plus dans ta table

[hachesse]

Envoyé par PassPassLeOuinje

tres franchement je vois pas en quoi le fait de creer un index ralenti tes insertion, ce n'est qu'un champ de plus dans ta table

très franchement, je vois pas pourquoi tu viens intervenir ici.

Les index rendent les insertions plus lentes car il faut mettre a jours l'index en plus de l'insertions des données dans la table.
Et c'est pareil pour les mise a jour et les suppressions.

De plus, les indexe ne sont pas un champ de plus dans la table.

[la drogue c'est mal]

je suis pas specialiste DBA et je suis pas la pour polémiquer. Ce sera donc ma derniere intervention sur ce sujet.

La mise a jour d'un index correspond à l'incrementation de l'index, c'est tout, juste une variable à mettre à jour. De plus, on ne fait pas de mise a jour de l'index ( ou alors une réindexation des tables mais c'est autre chose ) et pour finir la suppression ne fait pas decrementer l'index.

un index n'est rien d'autre qu'une variable auto incrémentale qui doit respecter des regles d'unicité et qui est quasiment automatiquement gérée ( donc optimisée ) par toute les bases de donnée

[fadace]

En SGBDR, un index est une structure de données, généralement un arbre binaire. Rien à voir avec une variable à instancier.

L'insertion dans un index dépend déjà du type d'index.

Il y a des index clusters, définissant - généralement - l'ordre physique de stockage des enregistrement dans la table. La dernière feuille de l'arbre EST la page de données.

Il y les index non cluster dont les dernières feuilles sont des pointeurs sur les pages de données

Il y a encore d'autres types d'index : bitwise et bitmap, très utilisés dans les bases de DW, permettant un fort taux de compression, donc plus de données sur une page d'index, donc des recherches bien plus rapides, mais sur des champs spécifiquement courts ou des données dont le spectre et plutôt étroit.

Dans des cas bien précis, un index peut RACCOURCIR les temps d'insertion : lors d'énormes accès concurrents, le fait d'indexer une table peut augmenter le nombre de pages qui vont être touchées, et donc améliorer la concurrence. Sans index, tout le monde essayerait d'écrire sur la dernière page de la hash table, d'où goulet d'étranglement compte tenu de la gestion des verrous...

[P'tit Jean]

Je dirais que la messe est deja dite,
je ne ferais que rajouter qu'il faut faire tres attention
au rajout d'index sur une table deja utilise par plusieurs
requetes ou procedure stockee, car il y a un risque de briser
leur perf.
Certaines requetes peuvent voir leur perf chuter par le fait
de passer par un nouvel index, cela peut casser un plan d'execution
deja existant et performant.

Donc penser a faire une etude d'impacte systematiquement sinon
ca peut etre le mur !

explain plan et autres TKPROOF (je sais c du Oracle et je connais
pas les equivalents sur les autres SGBD) devraient aussi aider.

P'tit Jean