生产库中遇到mysql的子查询

  • 时间:
  • 浏览:0

group by i_id;

改造后,sql的执行时间降到1000ms以内。

FROM (SELECT distinct i_id FROM table_data

select  i_id, sum(i_sell) as i_sell

大伙儿将子查询改为了关联,共同在子查询中添加distinct,减少t1关联t2的次数;

(备注:sql的业务逻辑还可以打个比方:先查询出10-07号新卖出的1000本书,而且 在查询这新卖出的1000本书在全年的销量请况)。

WHERE gmt_create >= ‘2011-10-07 00:00:00’) t1,  table_data t2

这条sql并全部都是老出 的性能问題在于mysql优化器在出理 子查询的弱点,mysql优化器在出理 子查询的只是,会将将子查询改写。通常请况下,大伙儿希望由内到外,先完成子查询的结果,而且 在用子查询来驱动外查询的表,完成查询;而且 mysql出理 为机会先扫描外面表中的所有数据,每条数据机会传到子查询中与子查询关联,机会外表很大一段话,没人性能上机会老出 问題;

where i_id in (select i_id from table_data where Gmt_create >= ‘2011-10-07 00:00:00’)

针对中间的查询,机会table_data这张表的数据有70W的数据,共同子查询中的数据较多,有少许是重复的,没人 就时需关联近70W次,少许的关联意味着这条sql执行了好多个小时也没人执行完成,只是 大伙儿时需改写sql:

SELECT t2.i_id, SUM(t2.i_sell) AS sold

from table_data

使用过oracle机会而且 关系数据库的DBA机会开发人员全部全部都是没人 的经验,在子查询上都认为数据库机会做过优化,要能很好的确定驱动表执行,而且 在把该经验移植到mysql数据库上,而且 不幸的是,mysql在子查询的出理 上有机会会愿意大失所望,在大伙儿的生产系统上就机会碰到了而且 问題:

WHERE t1.i_id = t2.i_id GROUP BY t2.i_id;