Salut,
suite à une analyse de l'activité Mysql sur un serveur, un hébergeur me remonte que les requêtes du type SELECT id_objet, type, date, url FROM spip_urls WHERE url=? sont les plus consommatrices en temps.
J'ai vérifié, et effectivement, la requête ne tape sur aucun index et cherche sur tous les enregistrements :
EXPLAIN SELECT id_objet, TYPE, DATE, url FROM spip_urls WHERE url='yo';
Hop,
L'espace occupé est assez négligeable, vu le gain de perfs.
Oui c’est un point performance que j’avais identifié mais pas pris le temps de regarder.
Peut-être tester sur des gros sites avec de grosses tables d’URLs si ce n’est pas le cas ici ?
Mais sur le principe je suis pour, à backporter sur la 3.2 et 3.1
Salut,
suite à une analyse de l'activité Mysql sur un serveur, un hébergeur me remonte que les requêtes du type SELECT id_objet, type, date, url FROM spip_urls WHERE url=? sont les plus consommatrices en temps.
...
Sans l'index, la requête prend entre 10 et 13 ms sur mon MariaDB local, avec l'index c'est moins de 0.5 ms.
Vous en pensez quoi ?
Qu’en SPIP2 cet index est présent. Pourquoi y a-t-il eu régression ?
esj
(eh oui toujous à l’écoute mine de rien)
Aucune idée de la raison, mais la clé primaire est maintenant composée de deux colonnes (id_parent,url), donc le "where url=?" ne tape pas dessus.
En fait, la clé primaire serait utilisée avec un where id_parent=? and url=?, ce qui n'est pas le cas.
Oui en effet c’est quand on est passé de url unique en clé primaire à (url+id_parent) unique pour pouvoir accepter 2 rubriques de même URL mais dont le parent est différent en url arborescente (qui permettent de distinguer rubriquemere1/rubriquefille de rubriquemere2/rubriquefille comme étant bien 2 rubriques différentes).
Du coup on a perdu la clé primaire et j’ai omis de réintroduire un index sur url pour compenser cette dégradation.