Discussion :

[randriano]

Bonjour,

Voici le code:

Code php :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Execute our SQL statement and return the result
$sql = "
    SELECT entreprises.id, entreprises.Nom, DateDebutActivites, SIRET
    FROM entreprises
    LEFT JOIN dirigeants
    ON (entreprises.id = dirigeants.IdEntreprise)
    WHERE 0=0
        AND (
            (entreprises.Nom LIKE '%" . $terms . "%')
            OR (DenominationSociale LIKE '%" . $terms . "%')
            OR (NomCommercial LIKE '%" . $terms . "%')
            OR (Enseigne LIKE '%" . $terms . "%')
            OR (Sigle LIKE '%" . $terms . "%')
            OR (SIRET LIKE '%" . $terms . "%')
            OR (dirigeants.Nom LIKE '%" . $terms . "%')
        ) 
    GROUP BY entreprises.id
    $limitClause";
$query = $this->db->query($sql);

Avec les 2 tables de 1000 lignes au total, ça marche mais avec la base de données complète (les 2 tables à 70000 lignes), le script ne se finit pas même au bout de 3 mn et fait planter la machine.
En fait c'est la dernière condition OR (dirigeants.Nom LIKE LIKE '%" . $terms . "%') qui est problématique.
Comme vous pouvez le voir, ce bout de code est utilisé pour une recherche donc une recherche qui ne donne pas de résultat au bout de 15 secondes maximum n'est pas intéressant.

Je me demande si un SELECT UNION pourrait bien être la solution.

[rawsrc]

Salut,

quel est le type de table utilisé pour le stockage ?

Code :

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

OR (dirigeants.Nom LIKE LIKE '%" . $terms . "%')

Y a un LIKE en trop.

[randriano]

Ne tenez pas compte du LIKE en trop, erreur de saisie!

Les tables sont en InnoDB!

[rawsrc]

Salut,

il n'y a pas 36 moyens d'optimiser des LIKE '%..%' avec des méta-carctères en début et fin. Dans ce cas de figure, indexer ne sert à rien à l'inverse d'un LIKE '..%' par exemple.

Après l'index optimisé pour ce genre de traitement : le FTS (full text search) n'est présent pour InnoDB qu'à partir de MySQL 5.6.4
Donc tu sembles coincé.

Si c'est vraiment central, il faudrait envisager la sous-traitance de ces requêtes en les passant à des moteurs du genre Lucene ou Sphinx.

En tout cas, le problème en l'état n'a pas de solution simple.

[grunk]

Pour la recherche full text en innodb on peut contourner le problème quand on à pas une version de mysql toute récente :

http://blog.oroger.fr/2009/11/03/mys...-table-innodb/

[randriano]

De plus, rares sont ceux qui utilisent déjà MySql 5.6.

J'ai transformé pour le test mes tables en MyIsam et j'utilise maintenant des index Fulltext!
Mais ça rame encore comme avec '%...%' pour fulltext. Voici ma requête:

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
SELECT 
  entreprises.Nom,
  dirigeants.Nom,
  MATCH(entreprises.Nom, dirigeants.Nom) AGAINST ('THU THON' IN BOOLEAN MODE) AS cpt 
FROM
  entreprises 
  LEFT JOIN
  dirigeants 
ON entreprises.id = dirigeants.IdEntreprise
WHERE MATCH(entreprises.Nom, dirigeants.Nom)
ORDER BY cpt

Rem: le contenu du WHERE est le même que le MATCH d'en haut mais le post ne marche pas quand je mets tout (bug de developpez.net)

Mon souci avec MyIsam c'est que c'est trop réputé comme moins performant qu'InnoDB, surtout pour une large base de données comme l'on utilise. C'est vrai on n'a pas besoin d'utiliser des clés étrangères réelles mais MyIsam est toujours lent par rapport à InnoDB non?

Voici un lien qui me fait hésiter: ici car selon ce lien si l'on ne veut donc pas utiliser des clés étrangères avec les intégrités référentielles, le seul avantage d'InnoDB c'est le système de récupération automatique en cas de crash puisqu'il est plus lent que d'autres et gourmand en ressources mémoires et en espace disque.

Mais bon le système ACID supporté par InnoDB est trop rassurant!

[redoran]

salut ; et si tu passe par une table temporaire ensuite tu déclenche ta requête de recherche sur la table memory , sûr tu passe de 3 mn a 0.03 secondes

[rawsrc]

Salut,

Je te l'ai dit optimiser des LIKE '%...%' sur MySQL relève d'une gegeure. Ce SGBD n'a rien d'exceptionnel et dès que tu montes un peu dans les tours, tu en touches très vite les limites. La preuve : une simple recherche texte suffit à le mettre sur les rotules.
Bref, pas de soluce miracle. Sans tomber dans des rustines bien crades, je pense que tu essaies de percer un trou avec une petite cuillère. A force tu devrais y arriver mais à quel prix...

[randriano]

salut ; et si tu passe par une table temporaire ensuite tu déclenche ta requête de recherche sur la table memory , sûr tu passe de 3 mn a 0.03 secondes

Je ne comprends pas le principe? Que mettre dans la table temporaire, comment penses-tu envoyer les données vers cette table, par trigger?

rawsrc > Oui j'ai retenu que l'optimisation d'un "LIKE '%...%'" n'est presque pas possible. Mais l'utilisation de FTS (Full Text Search) n'est pas à priori bénéfique non plus selon le test que j'ai fait. Je suis confus également sur le choix d'utiliser soit InnoBD plus sécurisé à défaut d'avoir l'indexation FullText, soit MyIsam plus rapide mais avec risque!*

Question: est-ce que le FULLTEXT peut s'utiliser sur des champs de type INT, FLOAT ou DATE?

[redoran]

En fait c'est la dernière condition OR (dirigeants.Nom LIKE '%" . $terms . "%') qui est problématique.

si tu supprime cette condition , qu'elle est le temps de réponse?

Je ne comprends pas le principe? Que mettre dans la table temporaire, comment penses-tu envoyer les données vers cette table, par trigger?

réponse:
La table temporaire est une construction volatile, stockée dans la mémoire du serveur Mysql, on utilisent ce type de création lors de requêtes complexes ( union, jointure........) qui sera automatiquement détruite à la fin de l’exécution du script
http://dev.mysql.com/doc/refman/5.0/...tml?ff=nopfpls
sinon vous pouvez rester sur innodb et enregistré sous une table MYISAM le résultat de la requête concernée par la recherche, cette dernière sera mise a jourr avec les triggers.
voila voilou ( c'est juste une proposition)

un lien intéressanthttp://dev.mysql.com/doc/refman/5.0/...xt-search.html

[randriano]

si tu supprime cette condition , qu'elle est le temps de réponse?

Ben le temps de réponse devient 2 secondes max mais là il n'y a plus de jointure si on l'enlève!

sinon vous pouvez rester sur innodb et enregistré sous une table MYISAM le résultat de la requête concernée par la recherche, cette dernière sera mise a jourr avec les triggers

En fait, si je veux utiliser fulltext, ne dois-je pas mettre les tables où effectuer les recherches en MyIsam mais pas seulement les résultats de la requête? Ou est-ce qu'une table temporaire supporte fulltext?

[redoran]

salut ; sans façon essaye une relecture de ce tuto http://sqlpro.developpez.com/cours/sqlaz/jointures/
essaye d'utilisé des alias pour les noms de table.
et cette condition sert a quoi ?

Code :

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

......WHERE 0=0.....

Code :

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

......WHERE 0=0....AND... (...OR...).

on a ici une logique booléenne...
http://python.developpez.com/cours/D...ion/and_or.php
je crois qu'il faut écrire la condition de la requête autrement ( par exemple utilisation de case...) .

[CinePhil]

On peut avoir la description complète des deux tables ?
Poste ici le résultat complet de SHOW CREATE TABLE nom_de_la_table

[gene69]

je crois qu'il faut faire autrement. par exemple si tu fais une table "de hachage" avec tous les tripplets de ta colonne. genre une vue matérialisée.. Ensuite tu cherches dans cette base tous les tripplets tappés par ton user (avec les index, ça va vite) et tu retournes l'intersections/l'union de tous les résultats qui retourne un nombre de réponses interessant (via du script).