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