Bien entendu, je ne parle pas de ma base mais de celle d'Eric... : 50061 éléments !!!
Et pour être plus précis aujourd'hui, c'est même 58345 éléments.

Si je faisais "QSearch  Prost GT Jabouille" chez moi cela devrait me retourner 0 / 800.
Pour ce genre de requête, je remercie Eric de nous permettre d'avoir une idée du résultat.
Et comme le dis si bien Mathias: "vive le mode "conseiller" (adviser)!"

8-)

Merci.
Dans l'etat actuel 8 seconde pour la requete n'est pas trop acceptable je pense (surtout qu'elle sera executee chaque fois qu'on appuie sur precedent/suivant ou on visualise une photo)... Neanmoins pour toi specialement, vimages, je ne pense pas que la requete tel quel est tres utile car tu n'as pas beaucoup des mots dans la description des photos/categories qui ne soient pas deja dans les tags.

pour info, radu: relevance = pertinence :-)

rvelices a écrit:

Merci.
Dans l'etat actuel 8 seconde pour la requete n'est pas trop acceptable je pense (surtout qu'elle sera executee chaque fois qu'on appuie sur precedent/suivant ou on visualise une photo)... Neanmoins pour toi specialement, vimages, je ne pense pas que la requete tel quel est tres utile car tu n'as pas beaucoup des mots dans la description des photos/categories qui ne soient pas deja dans les tags.

Il me semble avoir qu'il fallait aussi des indexs fulltextmachinchose, je ne sais exactement, ca vous parle?

mathiasm a écrit:

pour info, radu: relevance = pertinence :-)

J'ai eu du mal à comprendre!

Pour clarifier les 2 type de recherche:
- l'ancienne reste tel quel
- la nouvelle apparaitra juste qq part sur la page index (dans le menubar ou ailleurs).

Les index fulltext ne sont pas necessaires si la recherche est en mode boolean (c'est le cas). Je vais voir si je peux faire la grosse requete autrement au depens de la qualite des resultats mais au profit du temps d'execution.

J'ai update ma page de recherche en faisant des variations sur la requete. Au retour de vimages je vais lui demander s'il peut remettre la nouvelle version sur son site pour que je teste si d'autres requetes sont plus rapides.

FullTextSearch a écrit:

SELECT id, MATCH(ft) AGAINST( "xxxxx yyyyy" IN BOOLEAN MODE) AS q FROM (
SELECT
  i.id,  CAST( CONCAT_WS(" ",
    i.file,
    IFNULL(i.name,""),
    IFNULL(i.comment,""),
    IFNULL(GROUP_CONCAT(DISTINCT co.content),""),
    IFNULL(GROUP_CONCAT(DISTINCT t.name),""),
    IFNULL(GROUP_CONCAT(DISTINCT c.dir),""),
    IFNULL(GROUP_CONCAT(DISTINCT c.name),""),
    IFNULL(GROUP_CONCAT(DISTINCT c.comment),"") ) AS CHAR) AS ft
FROM
  (
  (
    (
    (phpwebgallery_images i LEFT JOIN phpwebgallery_image_tag it ON i.id=it.image_id )
      LEFT JOIN
    phpwebgallery_comments co on i.id=co.image_id
  )
    LEFT JOIN
  phpwebgallery_tags t on t.id=it.tag_id
  )
    INNER JOIN
  phpwebgallery_image_category ic on ic.image_id=i.id
  )
    INNER JOIN
  phpwebgallery_categories c on c.id=ic.category_id
GROUP BY i.id)  AS Y
WHERE MATCH(ft) AGAINST( "xxxxx yyyyy" IN BOOLEAN MODE)
ORDER BY q DESC LIMIT 0,50
(this query time : 0.320 s)
(total SQL time  : 0.324 s)
(total time      : 0.368 s)

Reste à éliminer les images n'appartenant pas à aucune catégorie autorisée.
Belle collection de jointures, j'ai un peu de mal à suivre. 8-D
Les colonnes de jointure sont toutes indexées à priori pas de pb.
Le MATCH() AGAINST, j'ai peur qu'il le calcule deux fois.
J'espère qu'il le calcule d'abord pour la clause WHERE puis uniquement sur les lignes résultantes pour calculer q avant de trier sur q
Comment le savoir EXPLAIN ?
Un test sans l'order by mais avec les deux MATCH()
Puis un test toujours sans l'order by et sans celui du select.
Appliqué à un résultat volumineux si la différence est > 20% il faut se poser la question de l'intérêt.
LIMIT ne pouvant être appliquée qu'après tri cela ne change pas grand chose pour MySQL sauf pour le serveur.

Mais pour moi, elle est parfaitement écrite, à la portée d'un développeur sur 10000 quand même mais Bravo.

Analysons vite fait le reste (j'ai abbrégé les requêtes)

Une remarque certaines queries applique le contrôle sur les id non autorisés d'autres non.

ImageFTSearch a écrit:

FROM phpwebgallery_images i
(this query time : 0.006 s)

Très speed.

ImageCommentsFTSearch a écrit:

FROM phpwebgallery_images i
LEFT JOIN phpwebgallery_comments co on i.id=co.image_id
(this query time : 0.063 s)

Un left join = x10

ImageCommentsCategoriesFRSearchTag a écrit:

FROM (
FROM (
  (
    phpwebgallery_images i LEFT JOIN phpwebgallery_comments co on i.id=co.image_id
  )
    INNER JOIN
  phpwebgallery_image_category ic on ic.image_id=i.id
  )
    INNER JOIN
  phpwebgallery_categories c on c.id=ic.category_id
(this query time : 0.049 s)
+
  FROM phpwebgallery_tags
(this query time : 0.028 s)
+
  FROM phpwebgallery_images
    INNER JOIN phpwebgallery_image_category AS ic ON id = ic.image_id
(this query time : 0.003 s)

Je m'attendais à pire du fait du double inner join, bonne surprise.
Total = 0.080 s

SmartSearch a écrit:

FROM phpwebgallery_tags
(this query time : 0.001 s)
+
  FROM phpwebgallery_categories INNER JOIN phpwebgallery_image_category ON id=category_id
(this query time : 0.002 s)
+
FROM (
    FROM phpwebgallery_images i
    LEFT JOIN phpwebgallery_comments co on i.id=co.image_id
(this query time : 0.037 s)
+
  FROM phpwebgallery_images
    INNER JOIN phpwebgallery_image_category AS ic ON id = ic.image_id
(this query time : 0.003 s)

Splendide
Total = 0.043 s

Conclusion : FullTextSearch est très belle pour les amateurs mais les autres sont très loin des 0.320 s
Je ne doute pas que la différence chez Eric sera encore plus grande.

Je te laisse rectifier mes remarques... Encore bravo !!!

8-)