Il y a déjà un index sur la date : <http://localhost/pma/sql.php?db=dc2&table=dc_post&sql_query=ALTER+TABLE+%60dc_post%60+DROP+INDEX+%60dc_idx_post_post_dt%60&message_to_show=L%27index+dc_idx_post_post_dt+a+%C3%A9t%C3%A9+effac%C3%A9&token=047782ad02ce1e0c108c5e15a2d9666d> dc_idx_post_post_dt
Franck Le 20 décembre 2012 10:53, Anne-Sophie Tranchet <[email protected]> a écrit : > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>> <[email protected]>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 >>>>>> [email protected] >>>>>> http://ml.dotclear.org/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://ml.dotclear.org/listinfo/dev >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://ml.dotclear.org/listinfo/dev >>> >>> >> > > _______________________________________________ > Dev mailing list > [email protected] > http://ml.dotclear.org/listinfo/dev > >
_______________________________________________ Dev mailing list [email protected] http://ml.dotclear.org/listinfo/dev
