Et voilà l'explain :

Requête SQL: explain SELECT P.post_id, P.blog_id, P.user_id, P.cat_id, post_dt, post_tz, post_creadt, post_upddt, post_format, post_password, post_url, post_lang, post_title, post_excerpt, post_excerpt_xhtml, post_content, post_content_xhtml, post_notes, post_type, post_meta, post_status, post_selected, post_position, post_open_comment, post_open_tb, nb_comment, nb_trackback, U.user_name, U.user_firstname, U.user_displayname, U.user_email, U.user_url, C.cat_title, C.cat_url, C.cat_desc FROM dc_post P INNER JOIN dc_user U ON U.user_id = P.user_id LEFT OUTER JOIN dc_category C ON P.cat_id = C.cat_id WHERE P.blog_id = 'open-time' AND ((post_status = 1 AND post_password IS NULL ) ) AND post_type IN ('post') AND ( (post_dt = '2004-10-12 10:33:29' AND P.post_id > 2795) OR post_dt > '2004-10-12 10:33:29' ) ORDER BY post_dt ASC, P.post_id ASC LIMIT 1;
Lignes: 3
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE P ref PRIMARY,dc_idx_post_user_id,dc_idx_post_blog_id,dc_idx_post_post_dt,dc_idx_post_post_dt_post_id,dc_idx_blog_post_post_dt_post_id,dc_idx_blog_post_post_status dc_idx_blog_post_post_dt_post_id 98 const 1 Using where
1 SIMPLE C eq_ref PRIMARY PRIMARY 8 dc2.P.cat_id 1
1 SIMPLE U eq_ref PRIMARY PRIMARY 98 dc2.P.user_id 1

Quant au schéma, c'est celui de Dotclear 2 actuel.


Franck



Le 20 décembre 2012 10:43, Franck Paul <carnet.franck.paul@gmail.com> a écrit :
Dans mon cas c'est sur MySQL.

Oui un index est peut-être nécessaire, c'est une des pistes possibles…

Franck



Le 20 décembre 2012 10:41, Julien Wajsberg <felash@gmail.com> a écrit :

sur mysql ou postgre ?

ajoute "explain" devant et mysql t'expliquera ce qu'il fait.
il manque peut-être des indexes ? (je connais pas le schéma donc j'essaie de deviner juste)


On 20 December 2012 10:33, Franck Paul <carnet.franck.paul@gmail.com> wrote:
'Jour les gens,

Les vacances arrivent, vous aller vous ennuyer, forcément, alors j'ai pensé à vous !

Voilà :

Lorsqu'on cherche le billet suivant d'un billet affiché, par exemple, on (enfin Dotclear) exécute ce
genre de requête :

SELECT P.post_id, P.blog_id, P.user_id, P.cat_id, post_dt, post_tz, post_creadt, post_upddt, post_format, post_password, post_url, post_lang, post_title, post_excerpt, post_excerpt_xhtml, post_content, post_content_xhtml, post_notes, post_type, post_meta, post_status, post_selected, post_position, post_open_comment, post_open_tb, nb_comment, nb_trackback, U.user_name, U.user_firstname, U.user_displayname, U.user_email, U.user_url, C.cat_title, C.cat_url, C.cat_desc FROM dc_post P INNER JOIN dc_user U ON U.user_id = P.user_id LEFT OUTER JOIN dc_category C ON P.cat_id = C.cat_id WHERE P.blog_id = 'open-time' AND ((post_status = 1 AND post_password IS NULL ) ) AND post_type  IN ('post') AND (     (post_dt = '2004-10-12 10:33:29' AND P.post_id > 2795)     OR post_dt > '2004-10-12 10:33:29' )  ORDER BY post_dt ASC, P.post_id ASC  LIMIT 1;

Sur mon blog ça donne ça :

# Query_time: 2.021316  Lock_time: 0.000466 Rows_sent: 1  Rows_examined: 12730

Pour résumer le nombre de lignes parcourues est assez volumineux.

Comment peut-on optimiser ce genre de requête ?

Vous avez jusque début janvier et d'ici là passez de bonnes fêtes !

Franck


_______________________________________________
Dev mailing list
Dev@list.dotclear.org
http://ml.dotclear.org/listinfo/dev



_______________________________________________
Dev mailing list
Dev@list.dotclear.org
http://ml.dotclear.org/listinfo/dev