IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 :

Optimisation de requête


Sujet :

Requêtes MySQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    74
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2005
    Messages : 74
    Par défaut Optimisation de requête
    Bonjour à tous,
    je rencontre un problème d'optimisation d'une de mes requêtes. je souhaite afficher les séjours répartis par communes d'origines des patients pour un établissment et un GHM donné.
    Voici les trois tables que j'intérroge dans ma requête :


    Voici ma requete trop longue (plus de 30 sec) ainsi que son plan d'éxécution :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    select Code_geo,  nb_sejour 
    from Sejour s 
    	inner join GHM g on s.Id_GHM=g.Id_GHM
    	inner join Etablissement e on e.id_etab=s.id_etab
    	inner join Geo ge on s.id_geo=ge.id_geo
    where 
    Code_GHM like '%C%' and
    finess like '690781810' 
    group by Code_geo;


    Le problème vient manifestement de la jointure avec la table Geo. En effet, quand j'affiche juste l'id_geo de la table sejour, mon temps d'execution passe sous la seconde

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    select id_geo,  nb_sejour 
    from Sejour s 
    	inner join GHM g on s.Id_GHM=g.Id_GHM
    	inner join Etablissement e on e.id_etab=s.id_etab
    where
    Code_GHM like '%C%' and
    finess like '690781810' 
    group by Code_geo;


    Pour info, voici les show index des tables sejour et geo :
    Sejour :

    GEO :


    Avez-vous des pistes de réflexion?

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    C'est parfaitement normal que ce soit lent, et cela le restera toujours du fait du LIKE '%C%'. En effet le seul moyen de résoudre cette recherche est de faire un scan. Et plus le volume augmentera plus les perf vont chuter dramatiquement.

    Ce qui est en cause ici, c'est votre modèle de données qui ne respecte pas les formes normale. En particulier ici la première forme normale est violée !
    Lorsque vous ne respectez pas les formes normales au cours de la modélisation, alors les performances sont irrémédiablement catastrophiques un jour ou l'autre !
    Dans votre cas, la recherche de '%c%' dans le code GHM (Groupement Hospitalier Medical ?) signifie que cette lettre toute seule est significative ! Dès lors pourquoi l'avez vous noyée dans votre code GHM ??? C'est cela le viol de la 1FN.

    Si vous aviez été sur un vrai SGBDR et non pas sur MySQL qui est un ersatz de SGBDR !!! - a lire : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/) il y aurait eut des moyens de contourner le problème, à l'aide par exemple de colonnes calculées, d'index sur fonction ou encore de vues indexées, mais aucun des ces outils n'est disponible dans ce SGBD pseudo relationnel !

    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre Expert
    Avatar de Maljuna Kris
    Homme Profil pro
    Retraité
    Inscrit en
    Novembre 2005
    Messages
    2 613
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 73
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 613
    Par défaut
    Saluton,
    En fait, réminiscences de mon DESS Traitement de l'Information Médicale Hsopitalière, les GHM sont des Groupes Homogènes de Malades, cette nomenclature nationale permet de codifier les pathologies afin de fournir des informations statistiques anonymes afférentes à l'activité médicale hospitalière.
    Et il vrai que le code est une clé composite et qu'il est maladroit d'avoir repris la nomemclature telle quelle.
    Kie lumo eksistas ankaŭ ombro troviĝas. L.L. Zamenhof
    articles : Comment émuler un tableau croisé [quasi] dynamique
    et : Une énigme mathématique résolue avec MySQL
    recommande l'utilisation de PDO (PHP5 Data Objects)

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    Oui, ça y est, ça me recolle. D’où la modélisation que j’avais fait pour AGGIR :
    http://blog.developpez.com/sqlpro/p9...r-la-grille-2/

    Ou pour la CIM :
    http://blog.developpez.com/exercices...s-de-la-cim10/

    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Membre chevronné
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    331
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2009
    Messages : 331
    Par défaut
    Regarde du côté des deux paramètres suivants :

    sort_buffer_size et join_buffer_size

    Rachid

  6. #6
    Membre confirmé
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    74
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2005
    Messages : 74
    Par défaut
    Merci pour vos réponses,
    Effectivement, je pense que ma modélisation des "Groupes Homogènes de Malade" (GHM) ne correspond pas aux règles de l'art. J'ai fait ce choix car les utilisateurs vont nécessairement sélectionner un ou plusieurs GHM lors de l'utilisation (donc pas comme dans mon exemple...).
    Je vais normaliser cette table pour analyser l'impact sur les performances.

    Néanmoins il me semble que le point bloquant est plutôt la jointure avec la table Geo non?

    L'utilisation de MySQL n'est pas une donnée que je maitrise; pour ma culture perso, que me conseillerez vous comme SGBD vraiment relationnel?

    Rachid, il me semble que join_buffer_size n'est utilisé que si la jointure se fait sans index, ce qui n'est pas la cas ici (cf plan d’exécution).
    Je bosse sur sort_buffer_size, mais je comprends pas exactement son fonctionnement et ça n'a pas l'air de changer grands chose.

    Note : il manquait le sum(nb_sejour) dans mes requêtes.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Access] Optimisation performance requête - Index
    Par fdraven dans le forum Access
    Réponses: 11
    Dernier message: 12/08/2005, 14h30
  2. Optimisation de requête avec Tkprof
    Par stingrayjo dans le forum Oracle
    Réponses: 3
    Dernier message: 04/07/2005, 09h50
  3. Optimiser une requête SQL d'un moteur de recherche
    Par kibodio dans le forum Langage SQL
    Réponses: 2
    Dernier message: 06/03/2005, 20h55
  4. optimisation des requêtes
    Par yech dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 21/09/2004, 19h03
  5. Optimisation de requête
    Par olivierN dans le forum SQL
    Réponses: 10
    Dernier message: 16/12/2003, 10h09

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