Discussion :

[Cyanatide]

Bonjour,
Dans mon SGBD, j'ai une table qui contient quelques millions de lignes, à chaque fois que je fais appel à cette table, ma requête prend un temps non négligeable!

Je me suis dit que l'index était la solution! J'ai suivit ce cours, mais il semble qu'il manque la partie 2...

Du coup pour compléter ça, le sujet n'est pas abordé dans le cours, mais j'imagine qu'on peut tout a fait créer plusieurs index sur une même table. Dans ce cas, comment le SGBD définit il l'index à utiliser? Sait il détecter le plus approprié en fonction de la requête ou doit on lui spécifier quelque part?

Ensuite pour le cas pratique, je veux optimiser ma table t_event qui contient la liste des évènement de taches exécutés sur différents sites distant. Voici la table:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
t_event
------------
f_event_id [PK]
f_date
f_task_id [FK]
f_event
f_error_code

Généralement les requêtes effectuées sur cette table me servent à:
- Lister l'état des taches en cours sur un site ( affichage du dernier f_event d'une liste de tache donnée)
- Récupérer toutes les tâche à un évènement donné.

Du coup je pensais faire un idexe sur f_task_id et f_event, et un autre sur f_event uniquement. Qu'en pensez vous?

[François DORIN]

Bonjour,

Du coup pour compléter ça, le sujet n'est pas abordé dans le cours, mais j'imagine qu'on peut tout a fait créer plusieurs index sur une même table. Dans ce cas, comment le SGBD définit il l'index à utiliser? Sait il détecter le plus approprié en fonction de la requête ou doit on lui spécifier quelque part?

Oui, il est tout à fait possible de créer plusieurs index sur une même table. Le SGBD choisi tout seul l'index à utiliser (même s'il est possible de lui dire, mais ce n'est pas recommandé). Il détecte le plus approprié en fonction des critères dans la clause WHERE, et aussi des statistiques dont l'optimiseur dispose.

Ensuite pour le cas pratique, je veux optimiser ma table t_event qui contient la liste des évènement de taches exécutés sur différents sites distant. Voici la table:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
t_event
------------
f_event_id [PK]
f_date
f_task_id [FK]
f_event
f_error_code

Généralement les requêtes effectuées sur cette table me servent à:
- Lister l'état des taches en cours sur un site ( affichage du dernier f_event d'une liste de tache donnée)
- Récupérer toutes les tâche à un évènement donné.

Du coup je pensais faire un idexe sur f_task_id et f_event, et un autre sur f_event uniquement. Qu'en pensez vous?

L'index sur f_event est effectivement une bonne idée. Maintenant, si l'objectif est de récupérer juste la tâche associée à l'événement (sans tenir compte de f_error_code ni de f_date), il est possible d'inclure la colonne f_task_id dans l'index. Ainsi, la récupération des tâches ne demandera qu'un accès à l'index, sans avoir besoin de récupérer d'information dans la table t_event.

Ensuite, pour lister l'état des tâches en cours sur un site, je placerais un index sur f_task_id et f_date, et j’inclurais la colonne f_event. Sur f_task_id d'abord, puisqu'il s'agit de récupérer les f_event d'une tâche donnée. Sur f_date ensuite, car cela permettra d'accéder directement au dernier événement. Inclure la colonne f_event dans l'index permettra d'éviter d'aller rechercher dans la table t_event les informations manquantes. Ton index est sera alors couvrant (l'index suffit pour répondre à la requête).

[Cyanatide]

Super merci pour ces précisions!
En faite, pour l'état des tâches en cours, j'ai déja dans ma table t_task un champ f_last_event_id géré par des trigger qui me permet de tout de suite récupérer le dernier évènement. A partir de la, le deuxième index que tu propose perd de son intérêt non? J'aurais sans doute meilleurs temps de définir un index sur f_task_id qui inclu f_event non? en fait c'est l'inverse du premier index proposé: cela me permet de récupérer plus rapidement l'historique des évènements pour une tâche.

[François DORIN]

A partir de la, le deuxième index que tu propose perd de son intérêt non?

A priori oui. Mais tu aurais du préciser plus tôt que tu avais déjà le _last_event_id d'accessible directement au sein de ta table t_task.

J'aurais sans doute meilleurs temps de définir un index sur f_task_id qui inclu f_event non? en fait c'est l'inverse du premier index proposé: cela me permet de récupérer plus rapidement l'historique des évènements pour une tâche.

Et c'est quasiment le deuxième index que je t'ai proposé, la colonne date en moins

[Cyanatide]

Oui, pardon j'aurais du mentionner le f_last_event_id dans mon premier message, mais au moment ou j'écrivais ce message je ne pensait pas que cela influerai sur ma demande.
Quoiqu'il en soit, problème résolu, merci pour ton aide.