requète sql très lourde si beaucoup de rubriques
on vient de tomber sur un cas un peu pénible avec la boite de sélection de rubriques en 4 colonnes de l'interface privée. on fait des tests sur un site ayant beaucoup de rubriques (plus de 2000) et ça rame affreusement.
après analyse, on a découvert que la requete suivante (au début de inc/plonger.php) mettait jusqu'à 7 secondes à s'exécuter :
$res = spip_query("SELECT rub1.id_rubrique, rub1.titre, rub1.id_parent, rub1.lang, rub1.langue_choisie FROM spip_rubriques AS rub1, spip_rubriques AS rub2 WHERE ((rub1.id_parent = $id_rubrique) OR (rub2.id_parent = $id_rubrique AND rub1.id_parent=rub2.id_rubrique)) AND rub1.id_rubrique!=$exclu GROUP BY rub1.id_rubrique");
en séparant la requète en deux, par un "union", on descend à des temps bien plus acceptables (<0,1 seconde) :
$res = spip_query(" SELECT rub1.id_rubrique, rub1.titre, rub1.id_parent, rub1.lang, rub1.langue_choisie FROM spip_rubriques AS rub1 WHERE (rub1.id_parent = $id_rubrique) AND rub1.id_rubrique!=$exclu UNION SELECT rub1.id_rubrique, rub1.titre, rub1.id_parent, rub1.lang, rub1.langue_choisie FROM spip_rubriques AS rub1, spip_rubriques AS rub2 WHERE rub2.id_parent = $id_rubrique AND rub1.id_parent=rub2.id_rubrique AND rub1.id_rubrique!=$exclu");
d'après la doc, le "union" est présent depuis mysql 4.0, donc pas de problème de compatibilité.
par contre, le "group by" dans l'original, l'absence de "order by" et l'utilité du "$exclu" m'échappent un peu. du coup, je suis pas sur que ça casse pas quelque chose ...