encore 1 petit coup de pouce please

[caro]

salut les gars
j'aimerais vraiment que vous me donniez des conseils car j'en peux plus.

comment optimiser MYSQL ???
j'ai une base avec 20 000 enregistrements (5000 en plus par mois) elle fait 5 Mo,
édité : pas faite de 10 tables mais 1 table avec 10 champs.
et il y a 3 index (sur les 3 champs de recherche).

mais ca rame :?
dès qu'il y a 30 connectés ca rame.
j'ai bo lire les tutoriels sur mysql je sais plus quoi faire,
quelqu'un pourrait me conseiller ?
merci merci merci

pour info :
je suis sur un serveur privé chez amen (virtuozzo) avec 1 Go de disque et 150 mo de mémoire. j'ai du installé ma base de données sur le serveur virtuozzo car elle est trop grosse pour l'installer sur les bases externes fournies avec le pack.
du coup je sature les ressources CPU avec la base et mon site en entier rame.

 

[Oxud]

150 Mo de Ram ?

J'essayerai déjà d'en rajouter un peu...

 

[yep]

optimise également les requêtes en php

 

[rituel]

Optimises la structure de ta base et tes requêtes surtout si elles brassent beaucoup de données.

Pour la structure de la base, je peux te conseiller la technique Merise. Pour les requêtes je te conseille de bien faire tes jointures et de respecter l'ordre de restrictivité décroissant des critères dans la clause WHERE.

 

[caro]

ouais mais les gars je suis en train de lire plein d'articles sur mysql mais c'est super compliqué tout ca :cry:

- optimiser requete php ?
(connexion, select where, deconnexion)
mais comment ?

- strucutre de la base :
je vais faire des recherches sur "Merise", merci
qu'est ce que c'est les "jointures" ?
"ordre de restricitivité décroissant dans where" kezaco ?

où puis je trouver de la doc qui soit compréhensible pour ces astuces.
et encore merci
comme d'hab vous êtes vraiment des tueurs et moi je suis à la traine
mais comment faites vous pour être aussi bon dans tous les domaines ???

 

[trix]

Caro,

D'apres les volumes que tu donnes, ta base ne devrait pas avoir de problemes particuliers, meme sur un serveur leger.

Tu dois avoir un probleme avec tes index qui ne sont pas efficaces. En clair, c'est pas parce que tu as un index sur chaque base qu'il va servir a quoi que ce soit.

Si tu sais a quoi ressemblent tes requetes, regardes du cote de 'EXPLAIN SELECT' dans la documentation MySQL. Ca devrait te permettre de voir si tes index sont efficaces, et eventuellement de mieux comprendre comment les ameliorer.

 

[itsme]

Ta base est meme toute petite par rapport a ce que l'on peut demander a mysql sans avoir besoin d'un serveur muscle.

Ce qui me semble plutot evident en lisant tes reponses, c'est que tu peches au niveau des connaissance techniques (qu'est ce que c'est les "jointures"). Une base mal definie, un ordre select mal agence ou des jointures mal faites peuvent faire ramer et meme provoquer des plantages a repetition.

Ce que tu as de mieux a faire est de te rapprocher de quelqu'un ayant la possibilite d'auditer la structure de ta base et les requettes qui lui sont soumises. Le top etant qu'il en profite pour t'expliquer ce qui ne va pas.

Au moins, tu sauras si c'est vraiment mysql qui est en cause ou tout simplement ton serveur a court de memoire.

mais comment faites vous pour être aussi bon dans tous les domaines ???

Comme toi... ca s'appelle l'apprentissage par l'echec

 

[stream]

Avec 30 connexions Mysql simultanées chez Amen, c'est le rupteur !!!

 

[maxttb]

Hummm... Je risque peut-être d'embrouillé un peu tout le monde, mais Merise n'est qu'une méthode de modélisation. Respecter la norme Merise pour creer une base de donnée ne la rend pas plus rapide, au contraire.
Faire des jointures decroissantes dans le WHERE est une bonne idée, mais MySQL propose des directives de jointure qui peuvent être PARFOIS plus performantes que celles dans le WHERE (notemment tout ce qui est JOIN, LEFT JOIN, etc etc). Ca prend moins de place en mémoire...
Je pense qu'il ne faut pas hésiter à utiliser des repetitions de données (afin de réduire le nombre de jointure gourmandes) mais avec modérations! Creer des index sur les données sujettes aux jointure me parait essentiel.
En tout cas, il est clair que tu ne peux pas savoir toute seule tout ce qu'il faut changer, il vaut mieux dans un premier temps demander à quelqu'un de ton entourage (ou du forum) un peu d'aide. Les bases de données, c'est facile de faire quelque chose qui marche, mais on a vite fait de mal optimiser et faire certaines petites erreurs par-ci par-la qui engouffre toutes les ressources de la machine...

 

[caro]

merci pour vos conseils les gars.

je viens de lire la définition des "jointures" sur mysql et je viens donc de m'appercevoir que c'est pas mon problème car j'ai qu' 1 seule table qui contient 10 champs.
je me suis trompé dans mon 1er post.

je vais donc essayer "explain select".
je vous tiens au courant.

merci beaucoup :wink:

 

[caro]

"explain select" me retourne que de bonnes nouvelles,
tout à l'air ok.

cependant je viens de mettre le doigt sur un indice,
c'est sur cette ligne que ca rame le plus :

$table=mysql_query("SELECT * FROM matable WHERE categorie='numero1' and reponse='0' ORDER BY datereponse DESC LIMIT $a,50");
while($ligne=mysql_fetch_object($table))
{
... tableau pour afficher les données, titres et dates..
}

la catégorie"numero1" contient 70% des données de la base,
on dirait que c'est parce qu'il y a trop de données à trier que ca rame, car les autres catégories vont plus vite.

ai je fais une bétise dans cette requete ?
y a t'il des astuces pour faire des requetes sur un champs très important ?


merci

 

[olivieri]

Si tu pouvais remplacer kes champs catégories et reponse par des champs numeriques au lieu de champs textes, ca optimiserait vachement les temps d'acces et de recherche.

 

[e-kiwi]

mais non, faut tout simplement utiliser un cache serveur .... fini les requetes SQL inutiles, fini les ralentissements, les too many connections....

 

[maxttb]

Il est clair que si une valeur peut selectionner 70% de tes enregistrements, alors une autre table à coté est largement justifiée.
Si vraiment tu n'as pas envie, tu peux peut-être faire un index sur ce champ, mais bon, c'est pas top top...