Discussion :

[mik3.42]

Bonjour,

je sollicite votre aide à propos d'une requête SQL que je trouve anormalement lente.

La requête est la suivante :

Code :

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

1
2
3
4
5
6
7
SELECT m.nom as magasin, p.reference, f.libelle
FROM VENTE_LIGNE vl
INNER JOIN VENTE v ON (v.vente_id = vl.vente_id AND v.date_vente = 20160801)
INNER JOIN MAGASIN m ON (m.magasin_id = v.magasin_id)
INNER JOIN PRODUIT p ON (vl.produit_id = p.produit_id)
INNER JOIN FAMILLE f ON (f.famille_id = p.famille_id)
INNER JOIN SOUS_RAYON s ON (s.sourayon_id = f.sourayon_id)

Cette requête prend en moyenne 30 secondes à s'exécuter.

Si j'enlève la dernière jointure à la table SOUS_RAYON, ma requête prend moins d'une seconde.

Code :

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

1
2
3
4
5
6
SELECT m.nom as magasin, p.reference, f.libelle
FROM VENTE_LIGNE vl
INNER JOIN VENTE v ON (v.vente_id = vl.vente_id AND v.date_vente = 20160801)
INNER JOIN MAGASIN m ON (m.magasin_id = v.magasin_id)
INNER JOIN PRODUIT p ON (vl.produit_id = p.produit_id)
INNER JOIN FAMILLE f ON (f.famille_id = p.famille_id)

J'ai beau chercher, impossible de comprendre pourquoi...

La base de données est sous MySQL.
Il y a bien des clés étrangères (donc index) sur chaque ID.

Nombre de lignes par table : VENTE_LIGNE (10 000 000), VENTE (38 000), MAGASIN (40), PRODUIT (90 000), FAMILLE (140), SOUS_RAYON (60).

Détails du schéma avec les clés primaires soulignées, et les clés étrangères avec un # :
VENTE (vente_id)
VENTE_LIGNE (vente_ligne_id, #vente_id, #magasin_id, #produit_id)
MAGASIN (magasin_id)
PRODUIT (produit_id, #famille_id)
FAMILLE (famille_id, #sousrayon_id)
SOUS_RAYON (sourayon_id)

La différence entre les 2 requêtes est donc une jointure sur une table de 58 enregistrements.
Je comprends que cela multiplie les données à interroger mais cette différence de temps me parait énorme.

Remarque : ma requête originale est bien plus complexe mais je l'ai simplifiée au maximum pour une meilleure compréhension.

Merci de m'éclairer.

[François DORIN]

Bonjour,

Il faudrait regarder les plans d'exécution. Il y a fort à parier que la présence/absence de la dernière jointure change complètement le plan d'exécution de la requête.

[escartefigue]

Bonjour,

Vu que la table sous_rayon ne contient que 60 lignes, même si l'index sur cette table est inefficient (non discriminant par exemple) un parcours séquentiel de cette table est très peu couteux si le nombre de lignes concerné par la requête sans cette jointure n'est pas énorme

Ou alors vos stats ne sont pas à jour et la table sous_rayon a bien plus de 60 lignes, auquel cas l'éligibilité de l'index devient sensible

Véirifez que les colonnes de jointure sont bien de même type et même longueur

[mik3.42]

Bonjour,

Vu que la table sous_rayon ne contient que 60 lignes, même si l'index sur cette table est inefficient (non discriminant par exemple) un parcours séquentiel de cette table est très peu couteux si le nombre de lignes concerné par la requête sans cette jointure n'est pas énorme

Ou alors vos stats ne sont pas à jour et la table sous_rayon a bien plus de 60 lignes, auquel cas l'éligibilité de l'index devient sensible

Véirifez que les colonnes de jointure sont bien de même type et même longueur

Oui c'est exactement ce que je me disais.
Ces quelques lignes ne devraient rien changer.

La table a bien 60 lignes et les colonnes de jointure ont bien le même type de données et la même longueur.

[escartefigue]

Je n'ai pas l'habitude de ce type de formalisme pour la stratégie d'accès, mais il semble que la stratégie d'accès à la table MAGASIN (m) soit du table scan quand vous utilisez la jointure alors qu'il y a un accès par PK quand vous supprimez cette jointure.

N'y a -t- il pas un filtre where sur le code magasin qui aurait sauté entre les 2 requêtes ?

[mik3.42]

Je n'ai pas l'habitude de ce type de formalisme pour la stratégie d'accès, mais il semble que la stratégie d'accès à la table MAGASIN (m) soit du table scan quand vous utilisez la jointure alors qu'il y a un accès par PK quand vous supprimez cette jointure.

N'y a -t- il pas un filtre where sur le code magasin qui aurait sauté entre les 2 requêtes ?

Non j'ai vérifié et je n'ai aucun WHERE dans la requête.

[mik3.42]

Bonjour,

Il faudrait regarder les plans d'exécution. Il y a fort à parier que la présence/absence de la dernière jointure change complètement le plan d'exécution de la requête.

En effet, j'avais remarqué que les plans d'exécution étaient différents.

Avec Jointure :


Sans Jointure :