Optimisation vue avec beaucoup de jointures

Bonjour,

Sur l'application sur laquelle je travaille comporte beaucoup d'attributs dont les valeurs sont prédéfinies. J'en profite pour factoriser au mieux mes données respectant au maximum les formes normales.
Souhaitant récupérer les véritables valeurs et non les clés, j'utilise une vue qui me renvoie une entité "prête-à-l'emploi". J'obtiens alors une vue avec 58 colonnes dont la plupart sont prédéfinies. Mes dépendances fonctionnelles se font sur 3 niveaux. J'arrive donc à une vue comportant 50 jointures et 2 restrictions.
Je viens de faire un test de montée en charge et c'est la catastrophe. 2 minutes pour 1000 lignes dans la vue, et une seule m'intéresse.
J'utilise MySQL et MyISAM. Toutes les colonnes utilisées pour jointure sont indexée.
Je ne veux pas mettre en péril la cohérence et cette vue est utilisée régulièrement.
Comment puis-je optimiser la chose ?

Merci à vous

salut,

vu la taille de ta vue, ça me parait pas choquant...

la question est si une seule ligne t'intéresse pourquoi ne pas utiliser directement la requête qui te rapatrie ce dont tu as besoin?

Bonjour,

Merci pour ta réponse. C'est ce que je fais :

Code:

---

1 2	SELECT .. FROM vue WHERE valeur unique = ?

---

J'ai l'impression que la vue n'est pas une une table recomposé mais une requête stockée. Du coup le sgbd execute les jointures et consomme la ressource.
Il faudrait que les données soient stockée physiquement.

Citation:

---

Envoyé par oneagaindoguys

Bonjour,

Merci pour ta réponse. C'est ce que je fais :

Code:

---

1 2	SELECT .. FROM vue WHERE valeurUnique = ?

---

J'ai l'impression que la vue n'est pas une une table recomposé mais une requête stockée. Du coup le sgbd execute les jointures et consomme la ressource.
Il faudrait que les données soient stockée physiquement.

---

je pense que l'implémentation des tables virtuelles que sont les vues met à jour le contenu à chaque accès en effet (plus simple à gérer même si moins efficace que seulement à la modification des tables sous-jacentes)

c'est surtout pratique pour un jeu bien déterminé de résultats... vu que ça revient à ré-exécuter la requête utilisée pour la création de la vue...

dans ton cas je pense que ce n'est pas adapté...:ccool:

En effet, une vue stocke une requête et pas des données. Comment je peux stocker les donnés pour obtenir de meilleurs perfs ?

Qu'est-ce qui pourrait donc être adapté à mon besoin ?

est ce que tu as vraiment besoin de consolider toute ta table principale?

si tu as besoin que d'une ligne... la requête directe est le mieux...

une vue aurait du sens si tu utilisais la même requête comme sous requête ou requête de jointure dans plusieurs grosses requêtes et que tu voulais en simplifier l'écriture ou factoriser ton code...

là c'est juste contre productif...

et sans plus d'infos dur de te conseiller...

une table temporaire n'aurait que la durée de la session et une permanente serait un bouffe ressources (en gros la somme de toutes les tables concernées)...et surtout si ce n'est que pour 1 requête sur la session...
et ça implique de faire des mises à jour de ces tables ce qui est toujours un risque de loupé...

MySQL dispose d'un optimiseur plus que bas de gamme. C'est pourquoi les vues sont contre performantes. En production elles sont catastrophiques.

Dans un bon SGBDR comme MS SQL Server, les vues sont optimisées (on appelle ce type d'optimisation "optimisation sémantique). Par exemples les jointures inutiles sont systématiquement abandonnées par l'optimiseur.
Voici ce que je dis dans la dernière édition (4e) de mon livre consacré à SQL (chapitre administration) :
5.1.2 – Optimisation sémantique

Cette méthode d’optimisation consiste à tirer parti des contraintes posées sur les colonnes (domaines SQL) ou sur les tables (intégrité référentielle via FOREIGN KEY ou validation via CHECK) pour simplifier les plans de requête.

..et plus loin dans un exemple...

En analysant le plan de requête que voici :

???

Figure 11.7 – simplification du plan de requête par optimisation sémantique
du fait des contraintes FOREIGN KEY (MS SQL Server).

On constate que, bien que la vue porte sur trois tables, deux tables seulement sont lues (T_SPORT_SPT et T_PRATIQUE_PTQ) pour résoudre la requête. Ceci est dû au fait que l’optimiseur considère inutile de lire la table des adhérents du fait qu’il ne peut pas y avoir de valeur de clef d’adhérent dans la table de jointure, autres que celles figurant déjà dans la table des adhérents du fait de l’intégrité référentielle. Sans cette optimisation, la lecture de la table des adhérents aurait augmenté très sensiblement le coût global de la requête.

Vous trouverez ce chapitre en ligne, à cette page :
http://compagnons.pearson.fr/synthex_sql_4/ressources/

Sur les pauvretés de MySQL, À me lire : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

A +

OK je vois. Le problème donc c'est que je fais mes jointure avant (par appel de la vue) pour ensuite faire ma restriction. C'est donc contre productif...

Merci

Merci ericd69 pour tes précisions. J'ai essayé avec la requête de la vue et effectivement la restriction se fait avant les jointures. Ca revient à ce que SQLpro disait, l'optimiseur n'est pas terrible. Du coup faire des vues sous MySQL n'est pas pas bien intéressant. :(