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

    2. 读取索引idx_aid_day_pv中的一行，然后查看是否满足条件，如果day字段不在条件范围内（20181220~20181224之间），则读取下一行；如果day字段在条件范围内，则把pv值累加（不是             在临时表中操作）；

    3. 读取索引idx_aid_day_pv中的下一行，如果aid与步骤1中一致且满足条件，则pv值累加（不是在临时表中操作）。如果aid与步骤1中不一致，则把之前的结果集写入临时表；

    4. 循环执行步骤2、3，直到扫描完整个idx_aid_day_pv索引；

    5. 对临时表根据num的值做优先队列排序；

    6. 根据查询到的前10条的rowid回表（临时表）返回结果集。

补充说明优先队列排序执行步骤分析：

1. 在临时表（未排序）中取出前 10 行，把其中的num和rowid作为10个元素构成一个小顶堆，也就是最小的 num 在堆顶。
2. 取下一行，根据 num 的值和堆顶值作比较，如果该字大于堆顶的值，则替换掉。然后将新的堆做堆排序。
3. 重复步骤2直到第 552203 行比较完成。

该方案可行性

实验发现，当我增加一行20181219的数据时，虽然这行记录不满足我们的需求，但是扫描索引的也会读取这行。因为我做这个实验，只弄了20181220~201812245天的数据，所以需要扫描的行数正好是全表数据行数。

那么如果该表的数据存储的不是5天的数据，而是10天的数据呢，更或者是365天的数据呢？这个方案是否还可行呢？先模拟10天的数据，在现有时间基础上往后加5天，行数与现在一样785102行。

drop procedure if exists idata;  
delimiter ;;  
create procedure idata()  
begin  
  declare i int;  
  declare aid int;  
  declare pv int;  
  declare post_day int;  
  set i=1;  
  while(i<=785102)do  
    set aid = round(rand()*500000);  
    set pv = round(rand()*100);  
    set post_day = 20181225 + i%5;  
    insert into article_rank (`aid`,`pv`,`day`) values(aid, pv, post_day);  
    set ii=i+1;  
  end while;  
end;;  
delimiter ;  
call idata();  
# Query_time: 9.151270  Lock_time: 0.000508 Rows_sent: 10  Rows_examined: 2122417  
SET timestamp=1552889936;  
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;  

这里扫描行数2122417是因为扫描索引的时候需要遍历整个索引，整个索引的行数就是全表行数，因为我刚刚又插入了785102行。

当我数据量翻倍之后，这里查询时间明显已经翻倍。所以这个优化方式不稳定。

方案2 扩充临时表空间上限大小

（编辑：晋中站长网）

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