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&gt;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

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

Quoique (je réfléchis tout haut), si on avait un index sur la date justement, on aurait pas besoin de parcourir autant de ligne non ? Le 20 décembre 2012 10:52, Anne-Sophie Tranchet <as.tranchet(a)gmail.com&gt; a écrit : Je débute en analyse de requête SQL mais ça a l'air plutôt bon : à chaque > fois, on utilise les clés primaires; pas de tables temporaires créées; on a > que du type ref ou eq_ref pour les jointures. > > > Le 20 décembre 2012 10:46, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a > écrit : > > 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&gt; 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&gt; 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&gt;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 >>>> >>>> >>> >> >> _______________________________________________ >> 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

Je doute que ça optimise grand chose, mais c'est pas bizarre ce bout là : AND ((post_dt = '2004-10-12 10:33:29' AND P.post_id > 2795) OR post_dt > '2004-10-12 10:33:29' ) Si j'ai bien compris, on s'en fout que le post_id soit > ou non à 2795, on cherche juste un post publié après le 12/10/2004 ? Sinon, oui, tu peux nous donner le résultat du explain ? Le 20 décembre 2012 10:41, Julien Wajsberg <felash(a)gmail.com&gt; 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&gt;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 > >