Discussion :

[everest31]

Bonjour,

je viens vers vous pour avoir des avis en terme de performance sur une base relative complexe et surtout très fournis.

Voici comment s'articule la base:
Une base articles avec environ 60 champs.
Dans ces 60 champs il y a 21 champs qui font référence un id d'autres tables (exemple couleur, taille, variétés etc...)
Par exemple un article dans la table article aura dans le couleur 1 et taille 1 , ce qui correspond a la couleur rouge dans la table couleur et a la taille S pour la table taille.

Donc je me pose une question maintenant au moment de l'affichage en terme de performance s'il vaut mieux que je passe par de multiple jointure sur ma requête ou si je crées une vue avec toute les jointures sur les champs de faites et que je requête direct sur ma vue ???

Avec une table démo de 600 articles en faisant un bench entre les deux versions, je trouve que globalement la version jointure a la volée est plus lente mais traite moins de ligne (d'apres les infos de la fonction EXPLAIN) alors que la version en utilisant la vue est légèrement plus rapide mais analyse plus de lignes.

La différence de temps est d'environ 0.08sec sur mon bench ce qui va un peu a l'encontre de ce que je pensais car j'avais toujours dans l'idée que moins de ligne étaient traité et plus le résultat était rapide

Par contre le problème c'est que le test est sur 600 articles alors qu'a terme la base va comporter environ 45 millions d'articles (il s'agit d'une base encyclopédique dans un domaine très particulier qui comporte énormément de déclinaison différente d'un même articles d'où la taille énorme)


merci d'avance de vos avis et/ou questions si besoin d'infos complémentaires.

PS: ces résultat sont obtenus avec un bench fait en C puisqu'au final le programme sera en C avec déjà une optimisation maximale du code a la compilation pour la machine de test, l'accés se fait via le socket.

[CinePhil]

En principe, ça devrait être à peu près pareil puisque une vue n'est rien d'autre qu'une requête enregistrée.

La différence qui peut arriver en production, c'est que vous n'aurez peut-être pas toujours besoin de faire toutes les jointures sur cette table alors que la vue va toutes les faire systématiquement. Je ne pense pas que l'optimiseur de MySQL soit assez "intelligent" pour le détecter et ignorer de lui même les jointures inutiles.

[everest31]

effectivement c'est ce qui me faisait penché pour partir sur les jointures meme si au final certaines requetes vont etre assez indigestes.

mais ce qui m'a interpellé et le résultat de l'analyseur d emYSQL qui me sort que la vue est plus rapide que la requete avec jointure.

je me disais donc que peut etre il y avait des optimisations spéciales dans le moteur de Innodb pour mieux optimiser le traitement d'une vue en interne qu'une requete avec jointure.

[CinePhil]

Si tu as lancé la requête avant la vue et que la vue a le même texte que la requête, il est possible que MySQL l'ai détecté et ait réutilisé son cache pour donner le résultat plus vite avec la vue qu'avec la requête.

[everest31]

effectivement je n'avais pas pris en compte un cache croisé sur les requêtes.

je vais refaire les tests en prenant soin de supprimer totalement les différents cache avant chaque requêtes pour voir.

[stos]

une vue n'est rien d'autre qu'une requête enregistrée

Si je ne me trompe pas, Mysql stocke bien la requête de création de la vue et non son résultat.
Je dirais donc qu'il n'est pas avantageux, en terme de performance, d'utiliser des vues avec Mysql.

[CinePhil]

Pas seulement MySQL mais tous les SGBD enregistrent le script SQL d'une vue, pas son résultat.
Certains SGBD plus évolués que le mauvais MySQL par contre ont aussi des vues matérialisées.

[everest31]

post sans utilité j'ai trouvé mon erreur.