salut a tous,
 
voila que OVH m'envoi un mail, stipulant que mes requetes SQL surchargent le serveur. Hier meatin, 10h. ils me disent, confirmez nous par retour de mail que vous ferez le necesssairte, et votre site sera de nouveau accessible. Aucun avertissement prealable... 13h30 hier je renvoi le mail disant que je fdais les chgt de scripts necessaire, et que je confirme pour reactiver ma base SQL.
resultzt, 24h plus tard, toujours plus aucune base de données dispo sous phpmyadmin, alors que mon amnager ovh indique qu'elle existe (ils l'ont desactivé). donc aucune restauration possible, rien n'y fait.
 
OVH, je vous hai !!!

je precise que la faiute m'incombe car j'ai utiliser des  
SELECT + FROM au lieu de SELECT count(*) FROM  
 
dans bien des requêtes, et je comprends la surcharge aisni générée.
Mais leur atttitude et la nonchalence affichées me mettent hors de moi.

C'est poour ca qu'il faut eviter a tout prix ovh..

oui, mais la ca se depasse, un tel j'menfoutisme. Quand je vois les heures que je passe à répondre aux mails et aux MP que les joueurs de SimCarriere m'envoyent sans arret, et je me dis que j'en suis meme pas salarié...
OVH ne fait ca que pour l'argent. Et je peux meme pas recupérer ma base pour aller chez un autre hébergeur, car elle est désctivée, donc impossible à sauvegarder...

Oui c'est un gros soucis ca, dès qu'ils reactivent sauvegarde et demenage...

c'est trop fort. Je les joints par telephone a 14h55. 15h25 => c'est réglé.
comme quoi.  
 
Moralité; des qu'il y a un prob, je les appelle !ouf, ils ont sauvés SimCarriere.

finalement, meme s'ils sont lents et ne disent jamais d'ou vient le prob, grace a eux mon site tourne quand meme.  
 
et pour info, le blaireaux c'est moi : j'avais une table avec une clé primaire qui devait pouvoir etre dupliquée. et un champ appelé "procédure", alors que ce nom est une fonction SQL.
 
Donc mea culpa...

Ha, les joies du mutualisé

j'hallucine !!!!
Ma base est encore desactivée ! ca fait TROIS fois cette semaine !!
j'en peux plus.
 
je vais héberger le jeu chez moi, en fin de compte.

aie

J'avais le même genre de pb en mutualisé chez ovh. Dès que tu veux utiliser un peu les moyens mis à disposition, ça gueule que tu consommes trop de ressources...
 
En fait l'idéal pour eux serait un site constitué uniquement de pages statiques et d'images. Pas de PHP, pas de SQL, ça consomme trop de ressources.

En même temps combien tu payes pour ce mutualisé ? Faut-il vraiment s'attendre à un service impeccable quand ça coûte 3 fois rien ?

non, c'est sur. A ce propos, je suis passé en hébvergement local (chez moi, quoi)
 
ccédez-vous au site de l'extérieur ?
juste pour savoir si j'ai tout bien configuré ?

Apparement c'est bon C'est pas super rapide, mais ça doit être la connexion là ( c'est sur les images la première fois )

c'est pas super rapide parce que mon serveur MySQL croule sous mes requetes pas optimisées... mais ca va aller mieux maintenant que j'ai pigé le principe des jointures SQL

Et juste pour info. Tu sais combien de requetes tu envoyait par jour vers le serveur quand tu était sur OVH ?

maintenant, ca va mieux...  ca tourne mieux.

Forcément si tu fais une requête sur plusieurs tables sans jointure, tu reçois en résultat le produit cartésien des tables; par exemple, si tu as 2 tables avec 100 enregistrements chacune, une requête sans jointure te retourne 100*100 = 10000 lignes: ça met vite un serveur à genoux !
 
Par contre j'ai pu constater à force de jouer avec mysql, que pour les petites sélections (genre une seule ligne), il vaut mieux utiliser 2 requêtes sur 1 table chacune que 1 requête sur les 2 tables, avec jointure.
 
Ex:
SELECT * FROM table1 WHERE id=4;
SELECT * FROM table2 WHERE id=4;
est plus rapide que:
SELECT * FROM table1, table2 WHERE table1.id=4 AND table1.id=table2.id;
 
Mais ça dépend peut-être aussi du type de table. Je pense que mysql fonctionne mieux avec beaucoup de "petites" requêtes qu'avec des "grosses"... Enfin, c'est ce que j'observe sur mon serveur, ça n'est pas une vérité absolue

Normalement ça revient au même, niveau traitement MySQL c'est la même chose entre ta jointure et faire les 2 séparées, sauf si tes index ne sont pas correctement mis sur les champs id.
 
ex :

 
C'est pareil
 
Sinon l'intérêt aussi de la jointure, c'est quand même de pouvoir la faire en faisant un WHERE sur une condition non commune aux 2 tables, du style :
 
SELECT * FROM table1, table2 WHERE table1.client="marcel" AND table1.id=table2.id;
 
Important à ce moment là d'avoir les index adaptés pour table1.client, table1.client et table2.client.

J'ai un site bittorent, parfois bien chargé lors d'1 sortie, chez OVH en mutualisé depuis 1an½ ou +, et j'ai jamais eu de soucis :s...

 
chargé ca veut pas dire grand chose. je me suis fait viré de chez OVH car j'avais un traffic de 80 mbits/s sur du mutualisé, ca c'est ce que j'appelle chargé.

Bah je sais pas trop mais ça faisais du 500 requete ttes les 3 minutes environ, après je sais pas comment faire pour connaître la BP utilisée ni le % pross, comme c justement du mutualisé.

 
500/180, pour simplifier on va dire que ça fait 3 requêtes par seconde.
Ce qui est ridiculement bas, donc ce n'est pas au niveau de SQL que tu consommes

le prob est résolu de toutes façons depuis que j'ai réécrit toutes mes requêtes.