sort buffer、内存临时表和 join buffer。这三个数据结构都是用来存放语句执行过程中的中间数据,以辅助 SQL 语句的执行的。其中,我们在排序的时候用到了 sort buffer,在使用 join 语句的时候用到了 join buffer。
建表;
create table t1(id int primary key, a int, b int, index(a));
delimiter ;;
create procedure idata()
begin
declare i int;
set i=1;
while(i<=1000)do
insert into t1 values(i, i, i);
set i=i+1;
end while;
end;;
delimiter ;
call idata();执行:
(select 1000 as f) union (select id from t1 order by id desc limit 2);explain一下:

可以看到实用了临时表(Using temporary)。
这个语句的执行流程是这样的:

如果使用了 union all ,就不需要临时表了,执行的时候依次执行子查询,得到的结果集直接返回给客户端。因此不需要临时表。
select id%10 as m, count(*) as c from t1 group by m;explain结果:

在 Extra 字段里面,我们可以看到三个信息:
这个语句的执行流程是这样的:
group by 执行流程:

内存临时表的排序流程如下:

如果不需要排序,可以加上order by null,因为group by 是默认排序的
select id%10 as m, count(*) as c from t1 group by m order by null;
由于表 t1 中的 id 值是从 1 开始的,因此返回的结果集中第一行是 id=1;扫描到 id=10 的时候才插入 m=0 这一行,因此结果集里最后一行才是 m=0。
内存临时表的大小是有限制的,参数 tmp_table_size 就是控制这个内存大小的,默认是 16M。
假如 把内存临时表的大小限制为最大 1024 字节,并把语句改成 id % 100,这样返回结果里有 100 行数据。但是,这时的内存临时表大小不够存下这 100 行数据,也就是说,执行过程中会发现内存临时表大小到达了上限(1024 字节)。
set tmp_table_size=1024;
select id%100 as m, count(*) as c from t1 group by m order by null limit 10;那么,这时候就会把内存临时表转成磁盘临时表,磁盘临时表默认使用的引擎是 InnoDB。
如果这个表 t1 的数据量很大,很可能这个查询需要的磁盘临时表就会占用大量的磁盘空间。
group + order by null 的结果(磁盘临时表):

至于为什么0在前面,是因为用了磁盘临时表,id取模 排序后存入临时表,临时的数据应该是0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,2,… 从这个磁盘临时表读取数据汇总的结果的顺序就是0,1,2,3,4,5。。。
B+树这种数据结构,这里会按照id%100(即m)的大小顺序来存储的,所以返回的结果当然也是有序的。
磁盘临时表使用的引擎是innodb,innodb是索引组织表,按主键顺序存储数据,所以是按照m字段有序的。
不论是使用内存临时表还是磁盘临时表,group by 逻辑都需要构造一个带唯一索引的表,执行代价都是比较高的。如果表的数据量比较大,上面这个 group by 语句执行起来就会很慢。
group by 的语义逻辑,是统计不同的值出现的个数。但是,由于每一行的 id%100 的结果是无序的,所以我们就需要有一个临时表,来记录并统计结果。
图10,group by 算法优化 - 有序输入:

如果可以确保输入的数据是有序的,那么计算 group by 的时候,就只需要从左到右,顺序扫描,依次累加。也就是下面这个过程:
按照这个逻辑执行的话,扫描到整个输入的数据结束,就可以拿到 group by 的结果,不需要临时表,也不需要再额外排序。
在 MySQL 5.7 版本支持了 generated column 机制,用来实现列数据的关联更新。你可以用下面的方法创建一个列 z,然后在 z 列上创建一个索引(如果是 MySQL 5.6 及之前的版本,你也可以创建普通列和索引,来解决这个问题)。
alter table t1 add column z int generated always as(id % 100), add index(z);然后group by
select z, count(*) as c from t1 group by z;这样就不需要临时表了

MySQL的字段默认值不可以是函数。除 TIMESTAMP字段可以用CURRENT_TIMESTAMP外。其它都使用常数为默认值。
在 group by 语句中加入 SQL_BIG_RESULT 这个提示(hint),就可以告诉优化器:这个语句涉及的数据量很大,请直接用磁盘临时表。
MySQL 的优化器一看,磁盘临时表是 B+ 树存储,存储效率不如数组来得高。所以,既然你告诉我数据量很大,那从磁盘空间考虑,还是直接用数组来存吧。
因此可以写成:
select SQL_BIG_RESULT id%100 as m, count(*) as c from t1 group by m;执行流程为:
这样得到有序数组,以及每个值出现的次数,即上面的图10。
使用 SQL_BIG_RESULT 的执行流程图:

使用 SQL_BIG_RESULT 的 explain 结果:

MySQL 什么时候会使用内部临时表:
EXPLAIN
SELECT a.*,count(*) FROM t1 a GROUP BY id DESC;-- 不使用临时表
EXPLAIN
SELECT a.*,count(*) FROM t1 a GROUP BY a DESC; -- 不使用临时表 a 是索引
EXPLAIN
SELECT a.*,count(*) FROM t1 a GROUP BY b DESC; -- 使用临时表
-- 尽量让 group by 过程用上表的索引,确认方法是 explain 结果里没有 Using temporary 和 Using filesort;
-- GROUP BY 会根据字段进行排序
select id%10 as m, count(*) as c from t1 group by m order by null;
-- tmp_table_size太小不能放下数据,会使用磁盘临时表,存放数据后会排序,排完后插入临时表。
set tmp_table_size=1024;
select id%100 as m, count(*) as c from t1 group by m order by null limit 10;
-- 使用了GROUP BY就会默认排序
SELECT * FROM (SELECT * FROM t1 GROUP BY a DESC) ab GROUP BY id order by null;
SELECT * FROM (SELECT * FROM t1 GROUP BY a DESC) ab GROUP BY id;