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 :
https://lh3.googleusercontent.com/_f...ait_Schema.png

Voici ma requete trop longue (plus de 30 sec) ainsi que son plan d'éxécution :

Code:

---

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;

---

https://lh6.googleusercontent.com/_f...e_Code_Geo.png

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:

---

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;

---

https://lh6.googleusercontent.com/_f...Exe_Id_Geo.png

Pour info, voici les show index des tables sejour et geo :
Sejour :
https://lh6.googleusercontent.com/_f...x%20sejour.png
GEO :
https://lh5.googleusercontent.com/_f...ndex%20geo.png

Avez-vous des pistes de réflexion?

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 +

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.

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 +

Regarde du côté des deux paramètres suivants :

sort_buffer_size et join_buffer_size

Rachid

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.

Citation:

---

Envoyé par stos

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.

---

Ça c'est important !

Citation:

---

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

---

Difficile à optimiser car MySQL implémente des index très rustiques sur objets géographiques (entre autres limites de MySQL...). A lire :
http://blog.developpez.com/sqlpro/p9...t-sur-l-index/
§ 1.7.5

Citation:

---

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?

---

PostGreSQL est pas mal, SQL Server est un poil plus pointu notamment pour la partie SIG...

A +

Bonjour à tous
Merci de vos conseils et de vos pistes de réflexion.
Ma requête de sélection est finalement assez bien optimisée car elle passe sous la barre des deux secondes sur ma base de prod.
J'ai fonctionné en deux étapes :
1) Normalisation de la table GHM sur les recommandation de SQLPro. Cela ne m'a pas fait gagner grand chose, mais j'y gagnerais sans doute plus tard...

2) Ecriture d'une requête dans le select pour "remonter" la jointure qui posais problème et me faisais perdre du temps :

Code:

---

1 2 3 4 5 6 7

select (select g.Code_Geo from Geo g where g.Id_Geo=s.Id_Geo) as code_cp, sum(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 "28Z07Z" and finess like '690781810' group by code_cp;

---

Bonne journée.