37 | 内部临时表

使用临时表的情况:

sort buffer、内存临时表和 join buffer。这三个数据结构都是用来存放语句执行过程中的中间数据,以辅助 SQL 语句的执行的。其中,我们在排序的时候用到了 sort buffer,在使用 join 语句的时候用到了 join buffer。

1. union 执行流程

建表;

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)。

这个语句的执行流程是这样的:

  1. 创建一个内存临时表,这个临时表只有一个整型字段 f,并且 f 是主键字段。
  2. 执行第一个子查询,得到 1000 这个值,并存入临时表中。
  3. 执行第二个子查询:
  • 拿到第一行 id=1000,试图插入临时表中。但由于 1000 这个值已经存在于临时表了,违反了唯一性约束,所以插入失败,然后继续执行;
  • 取到第二行 id=999,插入临时表成功。
  1. 从临时表中按行取出数据,返回结果,并删除临时表,结果中包含两行数据分别是 1000 和 999。
    在这里插入图片描述

如果使用了 union all ,就不需要临时表了,执行的时候依次执行子查询,得到的结果集直接返回给客户端。因此不需要临时表。

group by 执行流程

select id%10 as m, count(*) as c from t1 group by m;

explain结果:
在这里插入图片描述
在 Extra 字段里面,我们可以看到三个信息:

  1. Using index,表示这个语句使用了覆盖索引,选择了索引 a,不需要回表;
  2. Using temporary,表示使用了临时表;
  3. Using filesort,表示需要排序。

这个语句的执行流程是这样的:

  1. 创建内存临时表,表里有两个字段 m 和 c,主键是 m;
  2. 扫描表 t1 的索引 a,依次取出叶子节点上的 id 值,计算 id%10 的结果,记为 x;
  • 如果临时表中没有主键为 x 的行,就插入一个记录 (x,1);
  • 如果表中有主键为 x 的行,就将 x 这一行的 c 值加 1;
  1. 遍历完成后,再根据字段 m 做排序,得到结果集返回给客户端。

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 语句执行起来就会很慢。

group by 的语义逻辑,是统计不同的值出现的个数。但是,由于每一行的 id%100 的结果是无序的,所以我们就需要有一个临时表,来记录并统计结果。

图10,group by 算法优化 - 有序输入:
在这里插入图片描述
如果可以确保输入的数据是有序的,那么计算 group by 的时候,就只需要从左到右,顺序扫描,依次累加。也就是下面这个过程:

  • 当碰到第一个 1 的时候,已经知道累积了 X 个 0,结果集里的第一行就是 (0,X);
  • 当碰到第一个 2 的时候,已经知道累积了 Y 个 1,结果集里的第二行就是 (1,Y);

按照这个逻辑执行的话,扫描到整个输入的数据结束,就可以拿到 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 优化方法 – 直接排序

在 group by 语句中加入 SQL_BIG_RESULT 这个提示(hint),就可以告诉优化器:这个语句涉及的数据量很大,请直接用磁盘临时表。

MySQL 的优化器一看,磁盘临时表是 B+ 树存储,存储效率不如数组来得高。所以,既然你告诉我数据量很大,那从磁盘空间考虑,还是直接用数组来存吧。

因此可以写成:

select SQL_BIG_RESULT id%100 as m, count(*) as c from t1 group by m;

执行流程为:

  1. 初始化 sort_buffer,确定放入一个整型字段,记为 m;
  2. 扫描表 t1 的索引 a,依次取出里面的 id 值, 将 id%100 的值存入 sort_buffer 中;
  3. 扫描完成后,对 sort_buffer 的字段 m 做排序(如果 sort_buffer 内存不够用,就会利用磁盘临时文件辅助排序);
  4. 排序完成后,就得到了一个有序数组。

这样得到有序数组,以及每个值出现的次数,即上面的图10。

使用 SQL_BIG_RESULT 的执行流程图:
在这里插入图片描述
使用 SQL_BIG_RESULT 的 explain 结果:
在这里插入图片描述

总结

MySQL 什么时候会使用内部临时表:

  1. 如果语句执行过程可以一边读数据,一边直接得到结果,是不需要额外内存的,否则就需要额外的内存,来保存中间结果;
  2. join_buffer 是无序数组,sort_buffer 是有序数组,临时表是二维表结构;
  3. 如果执行逻辑需要用到二维表特性,就会优先考虑使用临时表。比如我们的例子中,union 需要用到唯一索引约束, group by 还需要用到另外一个字段来存累积计数。

原则

  1. 如果对 group by 语句的结果没有排序要求,要在语句后面加 order by null;
  2. 尽量让 group by 过程用上表的索引,确认方法是 explain 结果里没有 Using temporary 和 Using filesort;
  3. 如果 group by 需要统计的数据量不大,尽量只使用内存临时表;也可以通过适当调大 tmp_table_size 参数,来避免用到磁盘临时表;
  4. 如果数据量实在太大,使用 SQL_BIG_RESULT 这个提示,来告诉优化器直接使用排序算法得到 group by 的结果。
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;
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

醋酸菌HaC

请我喝杯奶茶吧

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值