10:46 a.m.
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(a)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(a)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(a)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(a)list.dotclear.org
>> http://ml.dotclear.org/listinfo/dev
>>
>>
>
> _______________________________________________
> Dev mailing list
> Dev(a)list.dotclear.org
> http://ml.dotclear.org/listinfo/dev
>
>