On trouve souvent dans Spip des requêtes SQL du genre :
... AND articles.date<NOW() ORDER BY articles.date DESC
Le test articles.date<NOW() ralentit beaucoup car il ne semble pas
utiliser l'index (alors que, si un index est mis sur la date, le tri
- ORDER BY - est ultra-rapide).
Or, ce test est complètement inutile. Si on n'a pas d'article dont la
date soit dans le futur (nos dirigeants prévoient l'avenir, certes,
mais quand même...), le tri suffit.
On trouve souvent dans Spip des requêtes SQL du genre :
... AND articles.date<NOW() ORDER BY articles.date DESC
Le test articles.date<NOW() ralentit beaucoup car il ne semble pas
utiliser l'index (alors que, si un index est mis sur la date, le tri
- ORDER BY - est ultra-rapide).
Or, ce test est complètement inutile. Si on n'a pas d'article dont la
date soit dans le futur (nos dirigeants prévoient l'avenir, certes,
mais quand même...), le tri suffit.
Puis-je donc virer ce test sans trop casser ?
Le mieux serait de n'appliquer ce test que si on demande "pas de publication
des articles post_datés" (ce qui se trouve dans spip_meta : cf
"post_dates").
C'est normalement le cas : as-tu bien choisi la bonne option dans la config
avancée ? (Te bases-tu sur les logs mysql ou sur le code de spip, quand tu
montres cette requête ?)
C'est normalement le cas : as-tu bien choisi la bonne option dans la config
avancée ? (Te bases-tu sur les logs mysql ou sur le code de spip, quand tu
montres cette requête ?)
PS: si effectivement ce test fait ramer, on pourrait cacher l'info dans un
booléen recalculé une fois par jour juste après minuit
Le mieux serait de n'appliquer ce test que si on demande "pas de publication
des articles post_datés" (ce qui se trouve dans spip_meta : cf
"post_dates").
Ah oui, ça marche. Merci.
C'est normalement le cas : as-tu bien choisi la bonne option dans la config
avancée ? (Te bases-tu sur les logs mysql ou sur le code de spip, quand tu
montres cette requête ?)
Sur les journaux de MySQL. J'aurai dû regarder le code de Spip
