( 转 ) 优化 Group By -- MYSQL一次千万级连表查询优化

概述：

交代一下背景，这算是一次项目经验吧，属于公司一个已上线平台的功能，这算是离职人员挖下的坑，随着数据愈来愈多，本来的SQL查询变得愈来愈慢，用户体验特别差，所以SQL优化任务交到了我手上。 
这个SQL查询关联两个数据表，一个是攻击IP用户表主要是记录IP的信息，如第一次攻击时间，地址，IP等等，一个是IP攻击次数表主要是记录天天IP攻击次数。而需求是获取某天攻击IP信息和次数。（如下SQL语句测试均在测试服务器上上，正式服务器的性能好，查询时间快很多。）

准备：

查看表的行数： 
 
 
未优化前SQL语句为：

SELECT attack_ip, country, province, city, line, info_update_time AS attack_time, sum( attack_count ) AS attack_times FROM `blacklist_attack_ip` INNER JOIN `blacklist_ip_count_date` ON `blacklist_attack_ip`.`attack_ip` = `blacklist_ip_count_date`.`ip` WHERE `attack_count` > 0 AND `date` BETWEEN '2017-10-13 00:00:00' AND '2017-10-13 23:59:59' GROUP BY `ip` LIMIT 10 OFFSET 1000

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18

先EXPLAIN分析一下： 

这里看到索引是有的，可是IP攻击次数表blacklist_ip_count_data也用上了临时表。那么这SQL不优化直接第一次执行须要多久（这里强调第一次是由于MYSQL带有缓存功能，执行过一次的一样SQL，第二次会快不少。） 

实际查询时间为300+秒，这彻底不能接受呀，这仍是没有其余搜索条件下的。 
那么咱们怎么优化呢，索引既然走了，我尝试一下避免临时表，这时咱们先了解一下临时表跟group by的使联系:

查找了网上一些博客分析GROUP BY 与临时表的关系 : 
　　1. 若是GROUP BY 的列没有索引,产生临时表. 
　　2. 若是GROUP BY时,SELECT的列不止GROUP BY列一个,而且GROUP BY的列不是主键 ,产生临时表. 
　　3. 若是GROUP BY的列有索引,ORDER BY的列没索引.产生临时表. 
　　4. 若是GROUP BY的列和ORDER BY的列不同,即便都有索引也会产生临时表. 
　　5. 若是GROUP BY或ORDER BY的列不是来自JOIN语句第一个表.会产生临时表. 
　　6. 若是DISTINCT 和 ORDER BY的列没有索引,产生临时表.

仔细按照上面分析一下，这SQL多是由于第二条致使的，blacklist_ip_count_date这个表的确主键不是IP，SELECT是多列的，那么咱们试试单独提出单表测试能不能避免临时表： 

很遗憾，并不能避免，可是咱们仔细看看这EXPLAIN 里面的KEY 分析，用的索引是date单字段的索引。这好像就是致使了第一条的问题了，至关于GROUP BY没有用索引。那么咱们试试强制使用IP单字段的索引呢？ 

这里看来的确是索引的问题，致使了临时表啊，然而再看看ROWS的数量，原来的9W变成了1552W，这不是否是捡了芝麻掉了西瓜吗？ 
这里单列索引 避免了临时表但是联系的行数又增长了，那么咱们再试试复合索引呢？ 
因而建立attack_count、date、ip的复合索引index_Acount_date_ip 

ROWS的行数770W并且仍是有临时表，看来这复合索引也是不可取。 
到此，避免临时表方法失败了，咱们得从其余角度想一想如何优化。 
其实，9W的临时表并不算多，那么为何致使会这么久的查询呢？咱们想一想这没优化的SQL的执行过程是怎么样的呢？

网上搜索得知内联表查询通常的执行过程是：
一、执行FROM语句 二、执行ON过滤 三、添加外部行 四、执行where条件过滤 五、执行group by分组语句 六、执行having 七、select列表 八、执行distinct去重复数据 九、执行order by字句 十、执行limit字句

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

这里得知，Mysql 是先执行内联表而后再进行条件查询的最后再分组,那么想一想这SQL的条件查询和分组都只是一个表的，内联后数据就变得臃肿了，这时候再进行条件查询和分组是否太吃亏了，咱们能够尝试一下提早进行分组和条件查询，实现方法就是子查询联合内联查询。 

这里EXPLAIN看来，只是多了子查询，ROWS和临时表都没有变化。那么咱们看看实际的效果呢？ 

可见，取出来的数据彻底如出一辙，但是优化后效率从原来的330秒变成了0.28秒，这里足足提高了1000多倍的速度。这也基本知足了咱们的优化需求。 
估计到这里，你猜这里就是所有的优化方案？不不不，整个优化过程怎么可能只是发现一个优化方案。还有其余方案我会分开文章写，具体请查看个人下一篇文章MYSQL一次千万级连表查询优化（二）。

总结：

整个过程当中咱们得知，其实EXPLAIN有时候并不能指出你的SQL的全部问题，有一些隐藏问题必需要你本身思考，正如咱们这个例子，看起来临时表是最大效率低的源头，可是实际上9W的临时表对MYSQL来讲不足以挂齿的。咱们进行内联查询前，最好能限制连的表大小的条件都先用上了，同时尽可能让条件查询和分组执行的表尽可能小。感谢您们的阅读，若是有更好的方案，欢迎留言交流！！！

版权声明：每一篇原创文章都是个人心血，欢迎转载，但请转载

 

原贴 : https://blog.csdn.net/Tim_phper/article/details/78344444