Discussion :

[clement106]

Bonjour,

J'ai construit une requête pour rechercher en FULLTEXT avec un ordre d'affichage lié au résultat de ma recherche. Le problème c'est que l' ORDER BY plombe ma requête. Je passe de 0.0113 à 1.0609

Voici la requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
SELECT t1_title,
MATCH (t17_description,t1_title) AGAINST ("+yamaha+fazer" IN BOOLEAN MODE) AS relevance
FROM node
INNER JOIN node_shop ON t1_nid = t17_nid
WHERE t1_status=1
AND MATCH (t17_description,t1_title) AGAINST ("+yamaha+fazer" IN BOOLEAN MODE)
ORDER BY relevance
DESC LIMIT 0,20

Temps pour la requête: 1.0609

Si l'on enlève ORDER BY relevance -> temps: 0.0113


J'ai essayé avec un tas de variantes mais rien y fait. Dès qu'il y a l'ORDER BY, ça prend des plombes.
Je ne comprend pas le pourquoi du comment... est-ce que quelqu'un aurait une idée?

Merci pour votre aide!

[Maljuna Kris]

Saluton,
Cet ORDER BY ne peut, par définition, utiliser aucun index.
Ceci explique cela.

[clement106]

Merci pour ta réponse.

Donc si j'ai bien compris, aucune solution possible pour booster le temps de réponse??

C'est vraiment dommage je trouve car l'intérêt pour moi était justement le classement part ordre de pertinance. 1 seconde sur le serveur de dev sera environ égale à 2.5 secondes sur le serveur de prod donc je crois que je vais continuer mes recherches en LIKE %%

[SQLpro]

Oui, enfin en comparaison, dans MS SQL Server le résultat est instantané car il créé l'index à la volée...

Bref, et comme je l'ai déjà dit dans cet article :
http://blog.developpez.com/sqlpro/p9...ext-search-no/
"
...pour le cas de MySQL il s'agit de faire croire que cela [la recherche textuelle] existe dans le SGBDR avec comme résultat quelque chose de difficilement exploitable en production
"
A +

[clement106]

Super ton article!

...pour le cas de MySQL il s'agit de faire croire que cela [la recherche textuelle] existe dans le SGBDR avec comme résultat quelque chose de difficilement exploitable en production

Je confirme...

[ericd69]

tu as essayé un truc simple comme stocker le résultat de ta requête sans order by dans une table temporaire sur laquelle tu fais un simple select avec le order by sur elle?

j'adore sqlpro et ses super démonstrations à l'emporte pièce...

fais un explain sur ta requête complète et sur celle sans order by, mais je pense que c'est un problème lié à bug de l'optimiseur qui génère des tables temporaires à chaque ligne à cause du order by... c'est pas le premier et le dernier bug comme ça...

donc diviser pour mieux régner:

• on génère les résultats sans classement (vu que ça marche bien)
• on les reclasse simplement pour la restitution

[clement106]

Non pas essayé. J'ignorais totalement que l'on pouvait faire celà!

Il faut que je la teste mais pour le moment je préfèrerais rester sur une requête simple. Je suis entrain de créer une fonction pour construire mes requêtes donc cette tables temporaires nécessiterait de revoir ma fonction en profondeur...

J'ai testé avec EXPLAIN et tu as vu juste! La requête avec ORDER BY utilise: Using where; Using temporary; Using filesort

Alors que celle sans utilise: Using where;

Entre temps j'ai trouvé une solution convenable en appliquant un MATCH() table par table, champs par champs.

La même requête avec ORDER BY est maintenant à 0.2152 ce qui est correct pour 30'000 enregistrement je trouve.

Voici la requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
SELECT t1_title,t1_nid ,
(MATCH (t17_description) AGAINST ("yamaha") + MATCH (t1_title) AGAINST ("yamaha")) AS relevance0 ,
(MATCH (t17_description) AGAINST ("fazer") + MATCH (t1_title) AGAINST ("fazer")) AS relevance1
FROM node INNER JOIN node_shop ON t1_nid = t17_nid
WHERE t1_status=1
AND (MATCH (t17_description) AGAINST ("yamaha") OR MATCH (t1_title) AGAINST ("yamaha"))
AND (MATCH (t17_description) AGAINST ("fazer") OR MATCH (t1_title) AGAINST ("fazer"))
ORDER BY (relevance0+relevance1) DESC
LIMIT 20

Cette requête avec EXPLAIN utilise aussi: Using where; Using temporary; Using filesort.
Je trouve plutôt étonnant que cette dernière sois plus rapide... Peut-être que le fait de ne pas utiliser " IN BOOLEAN MODE" y contribue.

[ericd69]

oui très certainement... vu que ça change le mode de comparaison...

après je te conseille de voir du coté des procédures stockées pour simplifier les appels