Oui, je l'aime bien cette formule.
Un peu comme ... Non, je les garde pour un autre jour.
;-)

VDigital a écrit:

ddtddt a écrit:

Genre les catégories qui se remplissent toutes seules avec les Tags ?

Non, il n'y a rien dans la db pour ces "catégories" qui n'en sont pas.
Ces catégories sont l'équivalent de recherches stockées ou d'accès par tags.
Ce n'est rien du tout.

Merci de ta réponse :-)

Merci de ces explications Vincent.

Je cherche depuis longtemps à optimiser l'accessibilité et la visibilité des galeries, surtout la principale.. la plus grosse.. d'ou mes posts du moment.. Il est des périodes ou j'ai un peu plus de temps (relatif) et j'en profite pour travailler sur ces sujets.

Content de comprendre que vous savez appréhander ces questions, quoique je le savais, je devrais plutot dire content de voir que vous vous en occupez...
Si cela semble long et difficile, il faut que cette préoccupation demeure prioritaire. la BDD est le noeux  de la galerie, et dès que celle-ci contient beaucoup d'informations à traiter, elle est soit le garant d'une bonne fluidité de la visite soit le caillou qui fera coincé une belle mécanique.

Nos visiteurs attendent toujours plus de vitesse dans leur navigation, nous devons assurer pour ne pas les décevoir.

merciiii...
amitiés,
éric.

Tous ces messages sont clairs.
Ils sont clairs et pas que Grum ou moi, aussi pour d'autres dans l'équipe.
Néanmoins (pour ceux qui suivent, j'adore ce terme autant que les "sushis"), il faut du temps pour les analyser, envisager des éventuelles modifications lesquelles peuvent provoquer d'autres anomalies.
Bref du temps, mais on regardera.

Exemple:

Gestionnaire
Handler_read_rnd               182 M                     
Le nombre de requêtes de lecture d'un enregistrement basée sur une position fixe.
Ce nombre est élevé si vous faites de nombreuses requêtes qui nécessitent de trier les résultats.
Vous avez probablement un grand nombre de requêtes qui demandent à MySQL de parcourir des tables en entier, ou vous avez des jointures qui n'utilisent pas correctement les clés.

=> Il faut trouver les requêtes correspondantes, faire des "explains", et imaginer d'autres solutions.
C'est souvent une clause 'where' qui n'est pas assez filtrante "Privacy level" ou "private" ou ...
C'est parfois des tris 'order by' en trop, pas besoin de trier les résultats ou tri déjà effectué au niveau d'un group by.
Ou pire des jointures (rapprochement de 2 tables) qui n'utilisent pas les clés existantes => Index supplémentaire à créer mais nous avons vu que parfois ajouter un index pour une requête peut ralentir d'autres requêtes.

Ça c'est pour une exception de la liste... et rien que pour celle-ci des heures à essayer de trouver une meilleure solution.
Le point n'est pas près d'être clos.
;-)

Bonjour
en premier lieu, je ne sais pas si ce sujet à sa place dans cette partie du forum, vous pouvez le déplacer si nécessaire...

Mysql !! Le gros morceau dans la gestion d'un serveur...

J'essaie depuis un moment de comprendre (à peu près) son fonctionnement pour tenter d'en optimiser les réglages...
Le soucis est que la doc disponible est la plupart de temps en Anglais :o(

Alors, je sais bien qu'il n'y à pas de recette miracle, que cela dépend du matériel, des autres parties logicielles utilisées.. et des sites que Mysql doit gérer...

Bon...
Toutefois, j'imagine que l'on doit pouvoir , à partir des logs, des outils d'analyses de Mysql, voir ce qui va ou ne va pas...

J'ai, par exemple, un rapport accessible via phpmyadmin, qui m'indique certains chiffres en rouge... il est question de clés, d'index...

je vous mets ci-dessous les quelques lignes dans lequelles apparaissent des chiffres en rouge..

Gestionnaire
Handler_read_rnd               182 M                     Le nombre de requêtes de lecture d'un enregistrement basée sur une position fixe. Ce nombre est élevé si vous faites de nombreuses requêtes qui nécessitent de trier les résultats. Vous avez probablement un grand nombre de requêtes qui demandent à MySQL de parcourir des tables en entier, ou vous avez des jointures qui n'utilisent pas correctement les clés. 
Handler_read_rnd_next       275 M           Le nombre de requêtes de lecture du prochaine enregistrement dans le fichier. Élevé si vous faites plusieurs parcours de tables. Ceci suggère que vos tables ne sont pas correctement indexées ou que vos requêtes ne sont pas écrites de façon à tirer parti des index que vous avez définis. 

Données temporaires 
Created_tmp_disk_tables         229 k         Le nombre de tables temporaires sur disque créées automatiquement par le serveur lors de l'exécution d'énoncés. Si la valeur du paramètre Created_tmp_disk_tables est trop grande, augmentez la valeur de tmp_table_size afin que les tables temporaires soient maintenues en mémoire au lieu d'être sur disque


Jointures 
Select_full_join                     13                              Le nombre de jointures qui n'ont pas utilisé d'index. Si cette valeur est supérieure à 0, vérifiez soigneusement les indexes de vos tables. 

Select_range_check                         8 613                                                    Le nombre de jointures sans clés qui vérifient l'utilisation de clé à chaque enregistrement. (Si ceci est supérieur à 0, vérifiez soigneusement les indexes de vos tables.) Select_scan 321 k Le nombre de jointures qui ont nécessité le parcours complet de la première table. 


Tables 
Opened_tables                27 k                          Le nombre tables qui ont été ouvertes. Si trop élevé, votre cache de table est probablement trop petite. 

Table_locks_waited                 1 271                        Le nombre de fois qu'un verrou de table n'a pu être acquis immédiatement, induisant un temps d'attente. Si ce nombre est élevé et que vous éprouvez des problèmes de performance, commencez par optimiser vos requêtes, puis subdivisez vos tables ou encore utiliser la réplication.