J'abonde dans ton sens : le tuning de la base de donnée impacte fortement les résultats !
Il suffit de regarder les changements en jouant sur le keybuffer de mysql : tapper le cache en mémoire évite les I/O, et les accès disques ce n'est pas vraiment très rapide comparé à la RAM...
Même le choix du moteur sur mysql ( myisam vs inodb ) n'est pas anodin !
Le premier, "mono-thread", peux sembler moins intéressant de prime abord, mais pour certaines applications sa rapidité de chargement ( load into table ) peux être intéressante et justifier son choix ! Il n'y a pas de réponse toute faite, tout dépend du contexte applicatif.
Par ailleurs par expérience j'ai constaté que 90% des problèmes de performance sur les SGBD sont due au code : boucle de requêtes, jointure à droite ou gauche à la va-comme-je-te pousse, utilisation d'une librairie d'abstraction qui génère des requêtes pas du tout optimisées... etc....
[^] # Re: premier bilan
Posté par ze_lionix . En réponse au message Performances des SGBD. Évalué à 3.
J'abonde dans ton sens : le tuning de la base de donnée impacte fortement les résultats !
Il suffit de regarder les changements en jouant sur le keybuffer de mysql : tapper le cache en mémoire évite les I/O, et les accès disques ce n'est pas vraiment très rapide comparé à la RAM...
Même le choix du moteur sur mysql ( myisam vs inodb ) n'est pas anodin !
Le premier, "mono-thread", peux sembler moins intéressant de prime abord, mais pour certaines applications sa rapidité de chargement ( load into table ) peux être intéressante et justifier son choix ! Il n'y a pas de réponse toute faite, tout dépend du contexte applicatif.
Par ailleurs par expérience j'ai constaté que 90% des problèmes de performance sur les SGBD sont due au code : boucle de requêtes, jointure à droite ou gauche à la va-comme-je-te pousse, utilisation d'une librairie d'abstraction qui génère des requêtes pas du tout optimisées... etc....
Fuse : j'en Use et Abuse !