Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Requêtes MySQL Discussion :

Requête très lente


Sujet :

Requêtes MySQL

  1. #1
    Membre habitué
    Homme Profil pro
    Consultant en technologies
    Inscrit en
    juin 2016
    Messages
    51
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant en technologies

    Informations forums :
    Inscription : juin 2016
    Messages : 51
    Points : 141
    Points
    141
    Par défaut Requête très lente
    Bonjour,

    la requête suivante (il y a un peu de php dedans):

    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    $sql = "SELECT nom_pays, libelle_".$nomen.", sum(valeur) as valeur, sum(masse) as masse
    			from pays as p , ".$impexp."_".$annee." as e, ".$nomen." as c 
    			where e.code_pays=p.code_pays and p.nom_pays = '".$pays."'".
    			" and c.code_". $nomen ." = e.code_".$nomen." and libelle_".$nomen." = '".$produit."'";
     
    			$result = mysql_query($sql,$lien);

    Me prend plusieurs seconde, quelle peut en être la cause?
    Une des tables impliquées comporte environ 1,5 millions de lignes, les autres quelques centaines.

  2. #2
    Membre habitué
    Homme Profil pro
    Consultant en technologies
    Inscrit en
    juin 2016
    Messages
    51
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant en technologies

    Informations forums :
    Inscription : juin 2016
    Messages : 51
    Points : 141
    Points
    141
    Par défaut
    J'ai exécuté une requête de ce type directement au niveau du SGBD, et cela a pris 10 secondes. En réduisant la table d'un million de lignes à 10 lignes, cela a été immédiat. La taille de la table serait donc à mettre en cause. Ce qui, fort naïvement, me surprend un peu puisque j'avais cru que SQL servait justement à gagner du temps sur des choses de ce genre. Or un pote va infiniment plus vite en faisant la même chose juste avec python/csv...

  3. #3
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 902
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 4 902
    Points : 13 816
    Points
    13 816
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    Pour expliquer les (contre-)performances d'une requête, il faut avant tout vérifier si les prédicats de filtrage (where) et de jointure (join) sont sargables ; c'est à dire s'il existe des index éligibles pour ces prédicats.
    Comme vous n'avez communiqué ni la description des tables ni celle des index éventuels, il est impossible de vous aider.
    Communiquez le DDL complet des tables et index, c'est à dire le script CREATE TABLE et CREATE INDEX pour tous les objets concernés par votre requête.
    Précisez également le type exact de chacune des host variables, car une host-variable d'un mauvais type compromet l'utilisation des index.

    Je vous invite à formuler les critères de jointures au moyen de l'opérateur JOIN comme le propose la norme SQL depuis plus de 20 ans.
    Vos requêtes seront plus faciles à lire et à maintenir

  4. #4
    Membre habitué
    Homme Profil pro
    Consultant en technologies
    Inscrit en
    juin 2016
    Messages
    51
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant en technologies

    Informations forums :
    Inscription : juin 2016
    Messages : 51
    Points : 141
    Points
    141
    Par défaut
    Bonjour escartefigue,

    création de la table "e":
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    $sql = "CREATE TABLE export_2018 (" .
    " `idExport` int NOT NULL," .
    " `mois` int NOT NULL," .
    " `code_CPF6` varchar(9) NOT NULL," .
    " `code_A129` varchar(4) NOT NULL," .
    " `code_NC8` int NOT NULL," .
    " `code_pays` varchar(2) NOT NULL," .
    " `valeur` int NOT NULL," .
    " `masse` int NOT NULL," .
    " `usup` int NOT NULL," .
    "  primary key(idExport))";

    création de la table "p":
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    $sql = "CREATE TABLE `pays` (" .
    " `code_pays` varchar(2) NOT NULL," .
    " `nom_pays` varchar(100) NOT NULL," .
    "  primary key (code_pays))";

    création de la table "c":
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    $sql = "CREATE TABLE `A129` (" .
    " `code_A129` varchar(9) NOT NULL," .
    " `libelle_A129` varchar(1000) NOT NULL," .
    "  primary key (code_A129))";

    Citation Envoyé par esacrtefigue
    Je vous invite à formuler les critères de jointures au moyen de l'opérateur JOIN comme le propose la norme SQL depuis plus de 20 ans.
    Vos requêtes seront plus faciles à lire et à maintenir
    J'ai eu un prof qui considérait que l'introduction de la formulation algébrique n'était pas tellement justifiée et qu'elle était moins claire. A vrai dire je suis d'accord, c'est pour cela que je ne l'utilise pas.

  5. #5
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 902
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 4 902
    Points : 13 816
    Points
    13 816
    Billets dans le blog
    1
    Par défaut
    Il faudrait examiner la requête telle qu'elle est générée et non le code PHP, pour vérifier comment sont construites les jointures
    Il est possible que les critères de jointures ne portent pas sur des colonnes de même type. Par exemple, dans la table pays, certains codes sont du varchar(2) d'autres varchar(4) ou encore de l'integer.

    Si les types ou les longueurs utilisés en jointure sont différents, alors la requête est dite "non sargable" c'est à dire qu'aucun index n'est éligible.

    Autre point non négligeable : vos pk portent sur des colonnes fonctionnelles, c'est une erreur à plusieurs titres.
    Tout d'abord en terme de stabilité : si les valeurs de code changent, vous devrez mettre à jour toutes les tables qui possèdent ces codes. Ce sera lourd et couteux.
    Ensuite en terme de performances : le varchar est ce qu'on fait de pire pour une PK, il est sensible à la collation, plus encombrant que de l'integer à nombre de valeurs possibles égal et il peut provoquer des déplacements de pages et data et index lors des mises à jour. De plus, pour certaines opérations (order by, group by, distinct), le varchar nécessite un alignement sur la longueur maxi.

    Enfin, choisir du varchar pour une longueur de 2 est contre-performant comparativement à du char : il faut tenir compte de l'attribut longueur dont le char n'a pas besoin.

  6. #6
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    YYYY
    Inscrit en
    mai 2002
    Messages
    19 141
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : YYYY
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 141
    Points : 45 203
    Points
    45 203
    Par défaut
    Citation Envoyé par Chezkele Voir le message
    J'ai eu un prof qui considérait que l'introduction de la formulation algébrique n'était pas tellement justifiée et qu'elle était moins claire. A vrai dire je suis d'accord, c'est pour cela que je ne l'utilise pas.
    être d'accord avec un vieux con, c'est un peu limite ! L'opérateur JOIN est fait pour la jointure. La clause WHERE pour la restriction… Vous pouvez aussi utiliser un marteau pour enfoncer une vis… Mais un tournevis est plus adapté pour visser qu'un marteau !!!

    Je suis toujours sidéré par la stupidité de certains professeurs qui ne se sont jamais recyclé ! C'est le triste sort de la France d'avoir des profs qui sont des fonctionnaires et ressassent le même cours pendant 40 ans, sans jamais se remettre en cause !

    Pour apprendre SQL, mon livre :
    https://www.amazon.fr/SQL-édition-Sy...ZKWHFTZH48GYB0


    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  7. #7
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    YYYY
    Inscrit en
    mai 2002
    Messages
    19 141
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : YYYY
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 141
    Points : 45 203
    Points
    45 203
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    ...De plus, pour certaines opérations (order by, group by, distinct), le varchar nécessite un alignement sur la longueur maxi.
    Alignement, oui, longueur maxi, ça dépend des SGBDR… Pour MySQL je sais pas, mais je pense que oui (et en UTF8 ça fait très mal !). Pour SQL Server c'est la moitié…

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  8. #8
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    4 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 79
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 4 096
    Points : 12 233
    Points
    12 233
    Par défaut
    Salut SQLPRO.

    Citation Envoyé par SQLPRO
    Je suis toujours sidéré par la stupidité de certains professeurs qui ne se sont jamais recyclé ! C'est le triste sort de la France d'avoir des profs qui sont des fonctionnaires et ressassent le même cours pendant 40 ans, sans jamais se remettre en cause !
    Sais-tu ce qu l'on dit au sujet des professeurs ?
    S'il est professeur, c'est qu'il n'est pas capable de faire autre chose.
    Ou si tu préfères, un professeur n'a aucune expérience du monde du travail !

    Mais pourquoi se remettre en cause ?

    Je prends l'exemple d'un professeur qui enseignait la mécanique.
    (j'ai vu cela à la télé dans un reportage consacré, à juste titre à l'enseignement en France)
    Tous ses élèves en sortant de l'école se retrouvent au chômage.
    On lui demande alors pourquoi enseigne-t-il ?
    Et il répond, pour ne pas se retrouver, lui aussi, au chômage.

    Ce qu'on leur demande, c'est d'enseigner, pas de répondre au besoin du marché du travail !

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  9. #9
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 902
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 4 902
    Points : 13 816
    Points
    13 816
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Salut SQLPRO.


    Sais-tu ce qu l'on dit au sujet des professeurs ?
    S'il est professeur, c'est qu'il n'est pas capable de faire autre chose.
    Ou si tu préfères, un professeur n'a aucune expérience du monde du travail !
    Ce n'est heureusement pas le cas de tous les professeurs, loin s'en faut. Il en existe aussi et fort heureusement de très bons.
    Notamment dans l'enseignement professionnel où certains professeurs sont aussi des entrepreneurs.

    Pour rester dans le même thème, j'ai eu un professeur de mécanique retraité de l'armée de l'air (la retraite arrive tôt dans l'armée).
    Et bien il était très bon. Il nous apprenait à diagnostiquer des pannes avec méthode et expliquait très bien, j'ai beaucoup aimé sa pédagogie et beaucoup appris grâce à lui, il donnait envie d'apprendre.
    Je me souviens aussi d'un prof d'agronomie qui partageait ces mêmes qualités. Il avait toujours des anectodes vécues à faire partager, même les pires cancres l'écoutaient avec attention.

  10. #10
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    4 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 79
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 4 096
    Points : 12 233
    Points
    12 233
    Par défaut
    Salut Escartefigue.

    Citation Envoyé par Escartefigue
    Ce n'est heureusement pas le cas de tous les professeurs, loin s'en faut. Il en existe aussi et fort heureusement de très bons.
    Oui, mais ils sont rares.

    Pour ainsi dire, j'ai eu très peu de bons professeurs. Heureusement pour moi que j'aime apprendre car si j'avais compté sur eux, je n'aurai jamais été ingénieur.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

Discussions similaires

  1. Requête trés lente > 20min
    Par ahmed. dans le forum Requêtes
    Réponses: 3
    Dernier message: 21/01/2013, 17h41
  2. Requête trés lente
    Par mercure07 dans le forum SQL
    Réponses: 22
    Dernier message: 29/03/2012, 18h46
  3. [AC-2007] Requête très lente depuis table externe en BD SQLServer2008
    Par alfhcg dans le forum Requêtes et SQL.
    Réponses: 8
    Dernier message: 28/10/2011, 00h19
  4. Requête très lente
    Par Korben-Dallas dans le forum Requêtes
    Réponses: 10
    Dernier message: 20/07/2011, 14h07
  5. Requêtes très lentes malgré peu de données
    Par The zxeno prophet dans le forum Requêtes
    Réponses: 8
    Dernier message: 12/01/2011, 14h09

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo