Salut
Alors je vais revenir sur un problème que j'avais déjà mentionné dans un topic en essayant d'être un peu plus précis
Si vous avez des tags sur vos sites, ou si vos articles peuvent être présents dans plusieurs catégories, vous avez bien une table de relation comme t_taxon_article (ou t_categorie_article ou t_tag_article) ? table ou vous mettez l'id de l'article et l'id du taxon (categorie, tag etc.) associé.
Dans ce cas comment faites vous vos requêtes et vos jointures pour afficher les articles de tel tag ou tel categorie ordonné d'une certaine façon (order by) ?
Et quels indexes utilisez vous ?
Voici mon problème.
J'ai actuellement ces 3 tables :
taxonomie = tag, categorie....
impossible d'arriver a optimiser ce type de requête :
pourquoi ? Tout simplement parce que mysql ne peut pas utiliser d'index étant donné que dans ma clause where et order by je fais appel a 2 tables différentes. L'idéal aurait été de créer un index combiné (ta.id_taxon, a.date_modif) ce qui est impossible.
Je me retrouve avec des « Using temporary; Using filesort » lorsque je vérifie avec EXPLAIN
L'une des solution (requête imbriquée) qui ne me donne pas entière satisfaction est la suivante :
En regardant avec EXPLAIN, j'ai bien des « Using where; Using index » et pourtant a certains moment en fonction du nombre d'articles à retourner, du nombre d'articles impactés etc (ou lorsque je viens de lancer mon serveur mysql). la requête grimpe vite en flèche en terme de temps d’exécution. Plus je vais dans les pages profondes également (avec le LIMIT)
J'ai également essayé de forcer des index ou du d'utiliser STRAIGHT JOIN, mais il est hors de question que je force mysql a faire d'une façon qui pour lui ne lui semble pas optimisé. Trop de risque qu'à un moment donné une requête me pète a la figure.
En gros comment faire lorsqu'on fait des jointures (inner, left, right) et qu'on fait appel a plusieurs tables dans le WHERE, ORDER BY etc. pour optimiser la requête et les indexes ?
Il y aurait bien la solution de dé-normaliser :
mettre le champ date_modif également dans table t_taxon_article, mais je trouve pas ça propre également. De plus dans mon cas je fais des tris sur plusieurs champs, et je me vois donc mal ajouter tous mes champs utilisés pour les tris également dans ma table t_taxon_article. :roll:
Ca fait des mois que je suis sur le même problème, a chaque fois je passe a autre chose parceque je ne trouve aps la solution. Mais il faudra bien que j'en trouve une satisfaisante si je ne veux aps finir un jour par faire cracher le serveur.
Et autre question :
A chaque fois que je démarre mon serveur mysql (Wampserver en local - pas essayé en prod), en début de journée, lorsque j’exécute pour la 1ere fois mes requêtes elles mettent parfois plus d'1s, par contre ensuite elles retombent a moins de 0,050 s
J'ai essayé de mettre sql_no_cache dans mes requêtes pour voir si c'était parce qu’elles étaient mises en cache mais ca n'a pas l'air d'être le cas.
Je pars du principe que si une requête peu mettre 1s pour s’exécuter (avant l'utilisation d'une quel conque cache mysql) c’est qu'elle n’est pas optimisée.
Alors je vais revenir sur un problème que j'avais déjà mentionné dans un topic en essayant d'être un peu plus précis
Si vous avez des tags sur vos sites, ou si vos articles peuvent être présents dans plusieurs catégories, vous avez bien une table de relation comme t_taxon_article (ou t_categorie_article ou t_tag_article) ? table ou vous mettez l'id de l'article et l'id du taxon (categorie, tag etc.) associé.
Dans ce cas comment faites vous vos requêtes et vos jointures pour afficher les articles de tel tag ou tel categorie ordonné d'une certaine façon (order by) ?
Et quels indexes utilisez vous ?
Voici mon problème.
J'ai actuellement ces 3 tables :
Code:
t_articles
id_article
titre
contenu
….
date_modif
en_ligne
t_taxon_article
id_article
id_taxon
t_taxon
id_taxon
taxon
taxonomietaxonomie = tag, categorie....
impossible d'arriver a optimiser ce type de requête :
Code:
SELECT a.id_article FROM t_article as a
INNER JOIN t_taxon_article as ta ON (ta.id_article=a.id_article)
WHERE ta.id_taxon=44
ORDER BY a.date_modif LIMIT 100,10Je me retrouve avec des « Using temporary; Using filesort » lorsque je vérifie avec EXPLAIN
L'une des solution (requête imbriquée) qui ne me donne pas entière satisfaction est la suivante :
Code:
SELECT a.id_article
FROM t_article as a
WHERE EXISTS (
SELECT 1 FROM t_taxon_article AS ta
WHERE ta.id_taxon=44 AND ta.id_article=a.id_article)
ORDER BY a.date_modif DESC
LIMIT 100,10En regardant avec EXPLAIN, j'ai bien des « Using where; Using index » et pourtant a certains moment en fonction du nombre d'articles à retourner, du nombre d'articles impactés etc (ou lorsque je viens de lancer mon serveur mysql). la requête grimpe vite en flèche en terme de temps d’exécution. Plus je vais dans les pages profondes également (avec le LIMIT)
J'ai également essayé de forcer des index ou du d'utiliser STRAIGHT JOIN, mais il est hors de question que je force mysql a faire d'une façon qui pour lui ne lui semble pas optimisé. Trop de risque qu'à un moment donné une requête me pète a la figure.
En gros comment faire lorsqu'on fait des jointures (inner, left, right) et qu'on fait appel a plusieurs tables dans le WHERE, ORDER BY etc. pour optimiser la requête et les indexes ?
Il y aurait bien la solution de dé-normaliser :
mettre le champ date_modif également dans table t_taxon_article, mais je trouve pas ça propre également. De plus dans mon cas je fais des tris sur plusieurs champs, et je me vois donc mal ajouter tous mes champs utilisés pour les tris également dans ma table t_taxon_article. :roll:
Ca fait des mois que je suis sur le même problème, a chaque fois je passe a autre chose parceque je ne trouve aps la solution. Mais il faudra bien que j'en trouve une satisfaisante si je ne veux aps finir un jour par faire cracher le serveur.
Et autre question :
A chaque fois que je démarre mon serveur mysql (Wampserver en local - pas essayé en prod), en début de journée, lorsque j’exécute pour la 1ere fois mes requêtes elles mettent parfois plus d'1s, par contre ensuite elles retombent a moins de 0,050 s
J'ai essayé de mettre sql_no_cache dans mes requêtes pour voir si c'était parce qu’elles étaient mises en cache mais ca n'a pas l'air d'être le cas.
Je pars du principe que si une requête peu mettre 1s pour s’exécuter (avant l'utilisation d'une quel conque cache mysql) c’est qu'elle n’est pas optimisée.
