加入收藏 | 设为首页 | 会员中心 | 我要投稿 宁德站长网 (https://www.0593zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

一次Group By+Order By性能优化分析

发布时间:2019-03-20 17:05:55 所属栏目:MySql教程 来源:周梦康
导读:副标题#e# 最近通过一个日志表做排行的时候发现特别卡,最后问题得到了解决,梳理一些索引和MySQL执行过程的经验,但是最后还是有5个谜题没解开,希望大家帮忙解答下 主要包含如下知识点 用数据说话证明慢日志的扫描行数到底是如何统计出来的 从 group by

问题与困惑

  1. # SQL1  
  2. select aid,sum(pv) as num from article_rank where day>=20181220 and day<=20181224 group by aid order by num desc limit 10;  
  3. # SQL2  
  4. select aid,sum(pv) as num from article_rank force index(idx_aid_day_pv) where day>=20181220 and day<=20181224 group by aid order by num desc limit 10;  
  1. SQL1 执行过程中,使用的是全字段排序最后不需要回表为什么总扫描行数还要加上10才对得上?
  2. SQL1 与 SQL2 group by之后得到的行数都是552203,为什么会出现 SQL1 内存不够,里面还有哪些细节呢?
  3. trace 信息里的creating_tmp_table.tmp_table_info.row_limit_estimate都是838860;计算由来是临时表的内存限制大小16MB,而一行需要占的空间是20字节,那么最多只能容纳                             floor(16777216/20) = 838860行,而实际我们需要放入临时表的行数是785102。为什么呢?
  4. SQL1 使用SQL_BIG_RESULT优化之后,原始表需要扫描的行数会乘以2,背后逻辑是什么呢?为什么仅仅是不再尝试往内存临时表里写入这一步会相差10多倍的性能?
  5. 通过源码看到 trace 信息里面很多扫描行数都不是实际的行数,既然是实际执行,为什么 trace 信息里不输出真实的扫描行数和容量等呢,比如                                                                                   filesort_priority_queue_optimization.rows_estimate在SQL1中的扫描行数我通过gdb看到计算规则如附录图 1
  6. 有没有工具能够统计 SQL 执行过程中的 I/O 次数? 

【编辑推荐】

  1. 什么影响了数据库查询速度、什么影响了MySQL性能?
  2. MySQL运维实战之PHP访问MySQL,你使用对了吗
  3. 记一次神奇的MySQL死锁排查
  4. 互联网公司面试必问的MySQL题目
  5. 开发人员不得不知的MySQL索引和查询优化
【责任编辑:庞桂玉 TEL:(010)68476606】
点赞 0

(编辑:宁德站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读