Recherche plein text Mysql (use full_text_index à yes)

Bonsoir,

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-04-19 23:28 (revision 668055213d7f926522223b8116cc1ba5d8ef0b9d)

[Database]
Vendor=2
ProductName=MySQL
ProductVersion=5.5.45-log

je butte sur un problème curieux: j’ai un champ indexé qui contient des alias (suites de termes, abréviations, etc.). Parmi les termes documentés, se trouvent (pour l’exemple) ‘MOP’ et ‘COP’. Ces termes sont bien reportés dans la table m_index mais lors de la recherche par l’index (searchindex), ils ne ressortent pas.

Le seul moyen de les faire trouver par searchindex est de leur ajouter un caractère (COPx, MOPx) et dans ce cas la recherche les trouve bien (en cherchant les termes ‘MOP’ et ‘COP’).

J’ai pu reproduire ce comportement avec d’autres termes comme “mid term plan” / “mtp”.

Il semble donc que les termes indexés ne soient “trouvables” que si ils font au moins 4 caractères.

Sur la version cloud simplicite.io (5.5.64-MariaDB) je n’arrive pas à reproduire le problème. Est-ce dû à la version de notre BD MySQL ? (5.5.45)

Je pense que l’index fulltext a besoin d’un minimum de caractères pour indexer les termes (ex: les articles a, the, le, la, les… sont ignorés). MySQL a besoin de 4 caractères par défaut.

Ca doit pouvoir se changer dans le /etc/my.cnf

[mysqld]
innodb_ft_min_token_size=3
ft_min_word_len=3

https://dev.mysql.com/doc/refman/8.0/en/fulltext-fine-tuning.html

ou la doc mariadb :

Bonjour François, merci beaucoup pour ta réponse rapide.

En effet, c’est ce que je craignais (au passage, je n’ai pas vérifié la variable USE_FULLTEXT_INDEX sur l’env simplicite.io, elle était à no). Depuis que je l’ai passée à yes, le problème est reproduit également sur cet env (sans surprise).

J’avais déjà exploré la piste des termes d’exclusion mais je n’y ai pas retrouvé nos trigrammes métiers (oui, nos documentations pullulent de codes à 3 caractères).

J’ai ouvert une demande de support auprès de nos architectes techniques pour étudier les impacts potentiels sur les performances et la volumétrie d’une reconfiguration à 3 caractères minimum.

Merci encore pour ton support.
Bruno

Sans ce paramètre (ou suivant les capacités de la base comme hsqldb), un simple best-effort en like '%token%' est réalisé sur la table m_index par Simplicité = c’est à dire un full scan non indexé sur la table. Ce qui est une catastrophe en terme de performances dès qu’on n’est plus sur une base de dev de qq milliers de lignes, et qu’on passe à qq millions en production.

Donc en test/production, il faut passer ce paramètre à yes et reconstruire l’index, sinon vous constaterez très rapidement des problèmes de performances en restant sur un simple “like”.

Oui, c’est bien ancré dans nos esprits (et cette option n’a pas été envisagée).
Nous étudions la possibilité de modifier le paramétrage du runtime MySQL pour passer la taille minimum des termes indexés à 3 caractères :)
Bruno