[Firebird 1.5] Problème avec les jointures et les index...

[Cyber Sinh]

Bonjour,

Pourquoi la première requête n'utilise pas les index sur la table T_TRACK (et s'exécute en 15 s !) alors que la seconde les utilise correctement (et s'exécute en 0 s!) ?

PS: J'utilise Firebird 1.5

Code :

1
2
3
4
5
6
SELECT t_album.c_id, t_album.c_artist, t_album.c_name
FROM t_album
INNER JOIN t_albumjoin ON t_albumjoin.c_album = t_album.c_id
INNER JOIN t_track ON t_albumjoin.c_track = t_track.c_id
INNER JOIN t_artist ON t_artist.c_id = t_track.c_artist
WHERE t_artist.c_name = 'Evanescence';

Plan
PLAN JOIN (T_TRACK NATURAL,T_ARTIST INDEX (ARTIST_PKEY),T_ALBUMJOIN INDEX (ALBUMJOIN_FK_TRACK),T_ALBUM INDEX (ALBUM_PKEY))

Plan Adpaté
PLAN JOIN (T_TRACK NATURAL,T_ARTIST INDEX (ARTIST_PKEY),T_ALBUMJOIN INDEX (ALBUMJOIN_FK_TRACK),T_ALBUM INDEX (ALBUM_PKEY))

------ Performance info ------
Prepare time = 0ms
Execute time = 15s 828ms
Avg fetch time = 565,29 ms
Current memory = 1 110 768
Max memory = 1 244 108
Memory buffers = 2 048
Reads from disk to cache = 3 680
Writes from cache to disk = 0
Fetches from cache = 5 112 579

Code :

1
2
3
4
5
6
7
8
SELECT t_album.c_id, t_album.c_artist, t_album.c_name
FROM t_album
INNER JOIN t_albumjoin ON t_albumjoin.c_album = t_album.c_id
INNER JOIN t_track ON t_albumjoin.c_track = t_track.c_id
INNER JOIN t_artist ON t_artist.c_id = t_track.c_artist
WHERE t_artist.c_name = 'Evanescence' AND
t_track.c_name = 'Anywhere' AND
t_album.c_name = 'Origin';

Plan
PLAN JOIN (T_TRACK INDEX (TRACK_NAME),T_ARTIST INDEX (ARTIST_PKEY),T_ALBUM INDEX (ALBUM_NAME),T_ALBUMJOIN INDEX (ALBUMJOIN_FK_TRACK,ALBUMJOIN_FK_ALBUM))

Plan Adpaté
PLAN JOIN (T_TRACK INDEX (TRACK_NAME),T_ARTIST INDEX (ARTIST_PKEY),T_ALBUM INDEX (ALBUM_NAME),T_ALBUMJOIN INDEX (ALBUMJOIN_FK_TRACK,ALBUMJOIN_FK_ALBUM))

------ Performance info ------
Prepare time = 0ms
Execute time = 0ms
Avg fetch time = 0,00 ms
Current memory = 1 128 940
Max memory = 1 244 108
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 783


Merci pour votre aide.
Cyber Sinh

[oceane]

Bonjour,

Juste une idée...pas une certitude

Visiblement la table t_track n'a pas d'index sur le champ t_track.c_id
.Dans la premiere requete, le seul utilisé pour la jointure; alors que dans la seconde, tu utilises t_track.c_name dans le where.

Quel sont tes index sur cette table ? Si c_id n'en fait pas parti, rajoute un index.

Océane

[Cyber Sinh]

Bonjour,

La table t_track a bien un index sur le champ c_id puisque c'est la clef primaire...

Je pense que la baisse de performance est simplement du à la différence de la requete. Dans la première, j'utilise une clause WHERE supplémentaire qui permet au moteur de disqualifier d'office un grand nombre d'enregistrements ! Dans la seconde requete, le moteur est obligé de parcourir tous les enregistrements de la table (plus de 3 000 000)...

Le problème, c'est que je ne sais pas comment mieux optimiser ma requête (tous les champs de tri / filtrage contiennent des index). Une idée ?