Bonjour,
J'ai de gros soucis de performances sur le site que j'administre à cause des requêtes SQL générées par le critère {xxx IN (array)}.
La structure particulière de notre site nous a obligés à y faire appel intensivement pour pallier à l'absence des critères optimisés {branche IN a,b,c} et {! id_mot IN d,e,f} de spip 1.9.2.
Le problème de ce critère c'est qu'il ne génère pas des requêtes SQL "IN" mais des "SELECT FIELD(a,b,c)" qui n'utilisent pas les index ni les clés (!!! j'ai encore du mal à le croire... quel intérêt ?). Résultat, la moindre requête parcourt l'intégralité des tables occasionnant une charge monstrueuse et des locks de tables interminables dès que le nombre de visiteurs simultanés augmente un peu.
Quelqu'un connaît-il un moyen pour contourner ce problème par l'un des moyens suivants :
- forcer mysql à utiliser les index sur les requêtes FIELD
- passer les critères de boucles IN sur des requêtes SQL... IN, qui, elles, utilisent les index (dans le genre intuitif, les devs ont fait fort sur ce coup-là)
- le tout en sachant que je suis pour l'instant bloqué sur spip 1.9.2, impossible de passer à 2.x avant la fin de l'année
J'ai longuement cherché dans les archives de toutes les listes et les forums, je n'ai trouvé qu'un fil sur la liste spip-dev reconnaissant en partie que le passage de IN à FIELD était un mauvais choix et qu'il faudrait certainement revenir en arrière, mais visiblement ça n'a pas été fait 
Merci d'avance à ceux qui pourront m'aider, j'aimerais vraiment ne pas avoir à réécrire tout mon code (plusieurs milliers de lignes)...
