Optimisation recherche sur grosse table mysql

[Zecat]

Le contexte : une table de 450.000 records et deux champs A (mediumint) et B(mediumint). je dois faire une recherche de type A like nnn AND B like mmmmmm ...

Est ce que cela présente un intéret de creer un champs C (varchar 10) dans lequel je concatene A et B pour au final me ramener a une recherche de type C like "nnn/mmmmmm" ? Ou est ce que mysql dispose d'optimisations internes qui font que le gain sera marginal ?

 

[zeb]

la première optimisation serait de se passer du like pour une égalité par exemple
peux tu donner un exemple concret de contenu

 

[Zecat]

sorry je pensais egal et j ai ecris like ....

Pou rle contenu c'est un table xref (ref croisées) et donc les deux champs medium int sont simplement des cle numeriques qui vont de 1 à 450000 pour la grande et de 1 à 250 pour le petite .... je vois pas quoi dire de plus

Sinon j'ai posté un autre post ... sans reponse sniff

https://www.webrankinfo.com/forum/t/du-bon-usage-des-tableaux-en-_session.163643/

si tu as un avis ?

 

[Blount]

Ça dépend de l'utilisation de la table.
La seule optimisation que je verrai par rapport à ce que tu nous rapporte, c'est la création d'un index sur les deux champs. Ceci permet à MySQL de stocker des informations sur les liaisons entre ces deux champs d'accélérer la recherche.
Grâce au index, le moteur n'est pas obligé de parcourir toute la table pour trouver ce que tu lui demandes, par exemple, il va savoir que xxx est présent n fois dans la colonne A, etc.

Après, si à coté la base de données dans sa globalité est mal construite, il est alors préférable d'y revoir sa structure.

 

[Zecat]

j ai oublie d epreciser que les deux champs A et B sont indexés of course ...

Donc ma question porte bien sur le gain apporté par une recherche monochamp alpah ^par <rapport a une recherche multi champs mediumint ...

Sinon cote structure de base, ca fait 20 ans que je bouffe du merise et de l'entité association ... alors je pense que de ce coté c'est blindé ... :wink:

 

[Zecat]

Grâce au index, le moteur n'est pas obligé de parcourir toute la table pour trouver ce que tu lui demandes, par exemple, il va savoir que xxx est présent n fois dans la colonne A, etc.

Je connais moins bien les entrailles de mysql que d'autres bdd. Mysql procède comment en interne ? il crée deux ensembles sous form de blob et fait une intersection de bits ?

 

[Blount]

Je ne connais pas vraiment le fonctionnement interne de MySQL, mais je sais que c'est un SGBD et que son rôle est de gérer des données. Il ne serait pas capable d'optimiser correctement ce genre de recherche, je doute qu'il serait utilisé par de gros site.
Tu sais, tes 450k d'entrées, c'est pas grand chose au final par rapport à d'autre grosse base de données.

Savoir comment procède MySQL, est-ce si important ? Non. Toi, tu es utilisateur. Ton rôle est de mettre en place les outils nécessaires pour indiquer à MySQL comment gérer tes données (quand plusieurs chemins sont possibles, tu lui indiques le meilleur, ici les index). À MySQL de se débrouiller à partir de là.

Si tu as des problèmes de performance, le souci n'est peut-être pas là.

 

[zeb]

Le coup des indexs ça peut se vérifier a la mano assez vite avec un script de bench maison qui font mouliner un peut la table sur des critères semblables.
Après faut aussi réfléchir si il n'existe pas une combinaison numérique des tes deux champs qui réduirait la requête a un simple sélect sur une égalité et là tu pourra difficilement faire plus rapide (c'est l'idée de ta concaténation mais version numérique)

 

[Zecat]

Après faut aussi réfléchir si il n'existe pas une combinaison numérique des tes deux champs qui réduirait la requête a un simple sélect sur une égalité et là tu pourra difficilement faire plus rapide (c'est l'idée de ta concaténation mais version numérique)

bon sang mais c'est bien sur ... arf je suis fatigué ce soir :

c=(a*1000)+b (puisque b ne depasse pas 250 ...)

et voila :wink:

 

[Zecat]

Savoir comment procède MySQL, est-ce si important ?

C'est mon coté "je veux voir sous le capot ... ca doit remonter à l'époque ou je codais en assembleur sur des "grosses becannes" de la taille de deux frigos ... avec 128k de memoire centrale (un truc que les moins de 40 ans ne connaissent pas) :mrgreen:

Si tu as des problèmes de performance, le souci n'est peut-être pas là.

nan pas de bleme de perf, le site est en dev avec une base de test toute petite mais comme je connais les volumétries avec la base pleine, j'anticipe ...

 

[zeb]

ou je codais en assembleur sur des "grosses becannes" de la taille de deux frigos ... avec 128k de memoire

Arf !!! tu jouais chez les riches ! quand j'avais 1k de dispo j'étais au 7e ciel perso
C'est d'autant plus amusant que de nos jours on croise des mecs qui sont capable de crawler 200 000 pages de l'autre côté de la planète pour voir si par hasard leur sitemap est a jour ...

 

[Zecat]

ou je codais en assembleur sur des "grosses becannes" de la taille de deux frigos ... avec 128k de memoire

Arf !!! tu jouais chez les riches !

De mémoire : 61/40 honeywell bull "boosté" en 61dps (j 'adore le terme boosté !!!) puis ensuite, mais la c'était ZE power :roll: , Mini 6/Dps 6. Bon j'ai dit 128k mais c'est au pif, me souviens plus .. si ca se trouve c'etait 24k ...