Reprise du message précédent :
Vi, merci. J'ai copié collé ca d'une page ou j'ai pas encore fait cette modif, mais on m'avait déjà fait la remarque

Oui, recentrons  
 
Quelques "optimisations" MySQL (mais généralisables aux autres SGBD), basées sur une idée : demander à MySQL directement l'information qui nous intéresse plutôt que transférer inutilement trop de données vers PHP  
 
- les colonnes
Si vous avez 10 colonnes dans votre table mais n'en voulez que 2, ne demander que ces 2 colonnes.
SELECT champ_1, champ_2 From table1
 
- les lignes
Idem, en utilisant WHERE pour enlever les lignes dont on n'a pas besoin
SELECT * from table1 WHERE champ_1 = 5
 
Le HAVING à un fonctionnement un peu similaire au WHERE à une différence près : il est exécuté à la fin de la requête, juste avant le transfert. C'est pratique pour supprimer des lignes sans pouvoir le faire avec un WHERE.
Par exemple, on à une table avec des lignes de facture (prix de l'article, quantité et identifiant de la facture), on veut le total de chaque facture, mais seulement celles dont le montant total est supérieur à 1000. On ne peut pas déterminer ce montant en traitant chaque ligne individuellement, donc le WHERE ne sera pas utile.
SELECT id_facture, SUM(prix * quantite) AS total_facture FROM lignes_factures GROUP BY id_facture HAVING total_factures >= 1000
 
- les tris
Autant les faire directement en MySQL si c'est possible
SELECT champ_1, champ_2 From table1 ORDER BY champ_1 ASC
 
- le comptage
Vous voulez savoir le nombre de lignes qui respectent une condition dans une table.
1ère solution : SELECT champ_1 FROM table_1 WHERE champ_1 = 5 puis utilisation de mysql_num_rows() pour connaître le nombre de lignes du résultat.
Là, MySQL va transférer toutes les lignes vers PHP, qui va les mémoriser. Tout ca, juste pour savoir combien il y en a.
 
2ème solution : SELECT COUNT(champ_1) AS nb_lignes FROM table_1 WHERE champ_1 = 5
Là, le résultat ne contient qu'1 ligne et 1 colonne. C'est quand même moins volumineux, non  
 
(bon, si vous voulez aussi parcourir le résultat, mieux vaut la 1ère méthode puisque vous aurrez de toute façon besoin de récupérer toutes les lignes)
 
- utilisation du LIMIT
Le LIMIT indique que l'on souhaite récupérer seulement une partie du résultat. Par exemple, en ajoutant LIMIT 10,25 à la fin de votre requête MySQL ne transférera que 25 lignes, en commencant à la 10ème.
 
Pratique, lorsqu'il est combiné avec un tri, lorque l'on veut afficher des données sur plusieurs pages, pour déterminer un "top n", récupérer les 10 données les plus vieilles/récentes...

Merci mrbebert : je copie/colle car c'est bien expliqué
 
En parlant de limit, n'est-il pas préférable d'ajouter limit 0,1 au bout d'une requête dont on sait qu'il n'y a qu'un seul résultat possible ?

 
A noter que la première solution est cela dit meilleure si on a aussi besoin des lignes en elles-memes, même si ça peut sembler évident.
 
Mon petit ajout à moi : utiliser mysql_fetch_assoc au lieu de mysql_fetch_array quand y'a pas besoin d'accéder aux colonnes par indices numériques (seulement par clé associative). C'est presque aussi rapide qu'un mysql_fetch_row.

Ah, c'est pas bete ca.
Et est-ce que quelqu'un connait le rapport de performances entre mysql_fetch_row, mysql_fetch_array et mysql_fetch_assoc ? ou un site qui en parle ?

Du point de vue de ce que tu veux faire toi, un fetch_accoc est bien assez rapide.. Pas besoin de se faire une branlette intellectuelle pour sortir 5 lignes de 5 champs sorties d'une table

Ca peut sembler évident, mais je l'ai quand même précisé  
 
 

Oui, ca permet d'indiquer à MySQL d'arrêter la recherche dès qu'il a trouvé ce qu'on voulait

 
C'est ça d'être un feignant de la lecture.

 
Commentaire trouvé sur php.net :
 
Benchmark on a table with 38567 rows:
 
mysql_fetch_array
MYSQL_BOTH: 6.01940000057 secs
MYSQL_NUM: 3.22173595428 secs  
MYSQL_ASSOC: 3.92950594425 secs  
 
mysql_fetch_row: 2.35096800327 secs  
mysql_fetch_assoc: 2.92349803448 secs  
 
As you can see, it's twice as effecient to fetch either an array or a hash, rather than getting both.  it's even faster to use fetch_row rather than passing fetch_array MYSQL_NUM, or fetch_assoc rather than fetch_array MYSQL_ASSOC.  Don't fetch BOTH unless you really need them, and most of the time you don't.

Sachant bien sûr que le mysql_fetch_array utilise MYSQL_BOTH par défaut.

Décidément je fait tout à l'envers moi, j'utilise fetch_array
 
Sinon est ce que toutes ces optimisations font qu'un gros gros site peu accueillir plus de visiteurs ou bien c'est juste au niveau de la rapidité des scripts s'il y à beaucoup de monde par exemple??  

Oui. Si les scripts sont plus rapides, le serveur pourra en traiter plus avant de saturer  
Une requête plus rapide sollicite moins le proc, les disques, et libère plus rapidement l'accès aux données.
 

Un bon informaticien, c'est feignant  
D'ailleurs, on passe notre temps à essayer de reporter un max de boulot sur les ordinateurs

 
Ok merci beaucoup, je me coucherais moins bete ce soir et maintenant je vais essayer de faire mes script au mieux
 

 
    vivement les procos hyper puissant et les disques durs ultra gros qu'ont puissent faire des scripts tout moches et tout lents sans avoir de problèmes       (non non je rigole )
 
 

Merci bcp : je vais donc rajouté ceci aux nombreuses requêtes du site le nécessitant

D'autres conseils d'optimisation ?

Là le truc qui me vient à l'esprit c'est de faire plutôt un grosse et élégante requete SQL plutôt qu'une moche ou plein de petites qui rebouclent avec du php .... Mais c le genre d'horreur que je suis le seul à faire lors de moment de dérive
Sinon un truc sympa dont je devrait surement me servir plus, un petit UPDATE table SET count = count+1 WHERE index_column=constant, au lieu d'un select, du calcul php puis d'un insert
 
D'autres trucs là http://sunsite.mff.cuni.cz/MIRRORS [...] ation.html

Mais alors dans ce cas-là, tu fais comment pour lister les 25 lignes à partir de la ligne 100 000 ? Tu te sers de l'id de la ligne (en admettant qu'elle a un champ id...) et tu prends les 25 premières à partir de la ligne ayant le 100 000ème id ?
Je sais pas si je suis très clair...

ORBER BY ID DESC LIMIT 25 p-e

 
tout depend de l'usage. Sur le forum que je developpe, je stocke la position d'un message dans son sujet. Je prefere faire une selection avec un WHERE pos>=100000 and pos <100025.

Comment fais-tu pour connaitre les IDs ? ça t'oblige à faire un Select avant non ?

Ca oblige à avoir un champ pos dans la table c'est tout

ça veut dire recomptage à chaque message effacé.
Cela dit, comme sur un forum on efface pas 15 messages par minute, ce n'est pas bête, j'y penserais pour mon prochain forum.

non ca veut dire decrement de 1 par message d'id superieur à celui supprimé(ou masqué). C'est correct sur la suppression se  fait sur un message recent. Par contre, c'est tres long pour un tres vieux message, car il va fair une grosse mise à jour.

C'est bien ce que je pensais.

Ouai, c'est ça que j'entendais par recomptage.
Mais je trouve quand même l'idée bonne.
La seul option qui doit faire souffrir à mort la base de données, c'est le massdelete sur un membre par exemple.

je n'ai pas encore implementé le mass delete. Mais il doit etre jouable de la faire plus finement en passant par une table de travail. Et ne faire qu'une seule requete de maj.
 
Mais effectivement, ca consomme des ressources. Perso, je vais le gerer en batch, hisstoire de ne pas bloquer le site.

Si j'etais vous je ferais ça en 2 fois. Quand on delete le topic, ca fous un flag particulier, et apres une fois par jour, la nuit, on lock les tables pendant quelques secondes et tout les messages avec le flag sont jartés, et la table compactée... Parceque sinon je vous le met dans le mille qu'il va y avoir des probleme d'acces pendant que vous deplacés vos 500'000 colonnes

C'est vrai que je n'avais pas pensé aux messages effacés ...  
Ca m'etonnerais que la reindexations soit une bonne solution, surtout que ça surcharge les index interne. Si on le fait en direct, la base prends un coup à chaque message effacé. Si on le fait en batch, il y a un laps de temps pendant lequel la page ne contiendra pas le bon nombre de messages.
Finalement, je me demande si le LIMIT est si mauvais que ça, le sgbd doit être surement optimisé pour sauter les x premiers enregistrements sans trop de peine.

Faudrais demander à Joce comment il fait, parce que sur HFR, y'a des sacré gros sujets.

Perso sur mon forum j'avais tout simplement un systeme de flag qui passaient a -1 pour effacer, et le contenu du message etait vider pour gagner un peu de place ... Apres ... reindexer le tout .. J'ai jamais essayé... faudrait demander a Arjuna ou aux autres DBA ce qu'ils en pensent

je dirais mysql_fetch_row < mysql_fetch_assoc < mysql_fetch_array < mysql_fetch_object (pas sûr à 100% pour ce dernier)
 
Perso j'utilise que mysql_fetch_row et mysql_fetch_assoc.
 

la rapidité d'exécution est améliorée et aide, mais vraiment un tout petit peu, à améliorer la charge. Ce qui charge vraiment, c'est les appels à la DB eux-mêmes.
 

en principe c'est LIMIT 100000, 25
 
Mais ça force la lecture des 100000 premiers enregistrements trouvés, donc t'as intérêt à plutôt trouver une méthode pour tomber directement dessus. Si les 25 sont les derniers, lis les à l'envers, car les remettre à l'endroit par après sera beaucoup moins coûteuse en traitement.
 

comme moi (on en avait beaucoup discuté sur le topic Forums de ce problème )
 
un peu contraignant mais bon
 

C'est super lourd à gérer, c'est le gros inconvénient de la méthode
mieux vaut se livrer à cet exercice pendant une maintenance
(en passant par la création de tables temporaires)
 
Si le mass delete n'est pas indispensable, mieux vaut virer le compte utilisateur et faire une mise à jour de ses messages comme c'est le cas maintenant ici. Son pseudo associé sera "utilisateur effacé", un truc du genre.
 

Une astuce comme on le disait plus haut, c'est qu'en début de topic, tu fais un LIMIT 0, 40 par exemple, et en fin de topic, tu fais un LIMIT 0, 40 ORDER <champ> DESC, histoire de minimiser le nombre d'enregistrements parcourus, à charge pour ton script de remettre ça en ordre
 
Mais c'est les deux cas courants. Faut encore pouvoir gérer la lecture au milieu d'un gros topic. Ici, ça marche bien, mais Joce ne donnera pas sa recette

Salut,
 

 
ça peut arriver, t'es pas forcément obligé de boucler, bref pour te montrer que ça ne change rien j'ai rajouté le cas utilisant un filesize :-)
 
"Ou le file qui retourne pas le meme type que le file_get_contents"
 
On s'en fout le but est d'ouvrir un fichier (d'où le sous titre du graphique)... Après tu utilises chaque fonction en fonction de tes besoins, mais j'ai expliqué pour UN seul besoin (l'ouverture d'un fichier comme ça, sans utilisation de tableaux ou traitements particuliers). Il est certain qu'il vaut mieux utiliser la fonction file() si c'est pour boucler sur le tableau généré ensuite plutôt que de passer par file_get_contents suivi d'un explode pour foutre tout ça dans un tableau, je pense que t'as compris où je voulais en venir...
 
"Ah, et aussi le switch VS if/elseif qui est pas vraiment significatif sur 2 cas"
 
Bah tu voulais que je fasse quoi ? remplir la condition de code n'a aucun sens !
 
Pour le mysql_fetch_row() je le rajouterai à l'occas ;-)
 
a ++
 
EDIT : pour la recette de Joce c'est surement un BETWEEN ou un WHERE mais avec de toute façon un champ id pour pouvoir ne pas utiliser de LIMIT

drapal, excellent topic  
puisse-t-il faire 80 pages !

Pour l'histoire du limit, si je comprend bien il vaut mieux borner avec des variables :
 

Devient  

 
Est bien ca ? ca me semble pas logique mais bon .....  

C'est pas forcément la même chose  
 
Si ta colonne "id" est indexée, la 2ème solution est la meilleure  
Mais ce n'est pas toujours possible de l'utiliser (par exemple, s'il y a des "trous" dans les valeurs de l'id).

y a aussi ce topic de Sh@rdar de quand vous n'étiez pas encore nés
 
http://forum.hardware.fr/hardwaref [...] 9259-1.htm

Si tu n'as aucun trou dans la colone id, aucune autre condition dans le where et que la requette est trié par "id", ca pourait être la même chôse (bien que "WHERE id >9 and id <26' " correspondrait mieux à l'exemple) mais rare sont les cas où on est sur à 100% que ca sera le cas pendant toute la durée de vie du script ou du programme utilisant cette table. Ce n'est donc pas toujours utilisable

<25 même. on en prend 15 à partir du 10 inclus
 

 
 
Ce topic va m'intéresser, parce que je fais un forum, mais dès qu'on est à plusieurs online qu'est ce qu'il rame
Et ca vient pas du server...
 
J'ai une petite question, j'ai une requete dans une boucle, cay mal non?
Mais je ne peux pas faire autrement... dans ce cas là je dois faire quoi? revoir la structure de mes tables? ou alors il n'y a pas une technique avec des jointures mysql ou autre? je ne sais pas vraiment l'utiliser...

que fais ta boucles? a quoi servent les requetes dedans?