MySQL深入33-内部临时表何时使用
# MySQL深入33-内部临时表何时使用
sort buffer、内存临时表和join buffer这三种数据结构都是用来存放语句执行过程中的中间数据，以及辅助SQL语句的执行。其中，sort buffer是用于排序的，join buffer是用于join语句的。
本文主要对内部临时表何时使用进行分析。
# 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);
union: 取这两个子查询结果的并集。
分析上述SQL语句：
EXPLAIN (select 1000 as f) union (select id from t1 order by id desc limit 2);
- 第二个子句使用了索引id。
- 第三行使用了临时表 (Using temporary)。
整个语句的执行流程如下：
- 创建一个内存临时表，这个临时表只有一个整形字段f，并且f是主键字段。
- 执行第一个子查询，得到 1000 这个值，并存入临时表中。
- 执行第二个子查询：
- 拿到第一行 id=1000，试图插入临时表中。但由于 1000 这个值已经存在于临时表了，违反了唯一性约束，所以插入失败，然后继续执行；
- 取到第二行 id=999，插入临时表成功。
- 从临时表中按行取出数据，返回结果，并删除临时表，结果中包含两行数据分别是 1000 和 999。
在本案例中内存临时表起到了暂存数据的作用，而且计算过程还用上了临时表主键id的唯一性约束，实现了union的语义。
# group by 执行流程
select id%10 as m, count(*) as c from t1 group by m;
这条语句是把主键进行%10分组统计，然后计算每个分组数量，并按照m的结果排序后输出。
分析上述SQL语句：
EXPLAIN select id%10 as m, count(*) as c from t1 group by m;
在 Extra 字段里面，我们可以看到三个信息：
- Using index，表示这个语句使用了覆盖索引，选择了索引 a，不需要回表；
- Using temporary，表示使用了临时表；
- Using filesort，表示需要排序。
整个语句的执行流程如下：
- 创建内存临时表，表里有两个字段 m 和 c，主键是 m；
- 扫描表t1的索引a，依次取出叶子节点的id值，计算id%10的结果，记为x；
- 如果临时表中没有主键为 x 的行，就插入一个记录 (x,1);
- 如果表中有主键为 x 的行，就将 x 这一行的 c 值加 1；
- 遍历完成后，再根据字段 m 做排序，得到结果集返回给客户端。
如果你的需求并不需要对结果进行排序，那你可以在 SQL 语句末尾增加 order by null
由于步骤3涉及到排序，内存临时表的大小是有限制的，如果内存临时表空间不够，就会把内存临时表转成磁盘临时表。
# group by 优化方法 - 索引
不论是使用内存临时表还是磁盘临时表，group by逻辑都需要构造一个带唯一索引的表，执行代价比较高。
试想以下为什么group by语句需要临时表？
因为group by 的语义逻辑，是统计不同的值出现的个数。但是，由于每一行的 id%100 的结果是无序的，所以我们就需要有一个临时表，来记录并统计结果。
那如果我们能够保证我们输入的数据有序的呢？
在确保输入的数据是有序的情况下，计算 group by 的时候，就只需要从左到右，顺序扫描，依次累加。也就是下面这个过程：
- 当碰到第一个 1 的时候，已经知道累积了 X 个 0，结果集里的第一行就是 (0,X);
- 当碰到第一个 2 的时候，已经知道累积了 Y 个 1，结果集里的第二行就是 (1,Y);
我们可以创建一个列z，让列z始终为该行id % 100，并在该列上加上索引：
alter table t1 add column z int generated always as(id % 100), add index(z);
优化后的group语句：
select z, count(*) as c from t1 group by z;
分析上述语句：
EXPLAIN select z, count(*) as c from t1 group by z;
从 Extra 字段可以看到，这个语句的执行不再需要临时表了。
# group by 优化方法 - 直接排序
上述的优化方法是通过加索引的方法实现的，如果存在不适合创建索引场景，那么我们如何对group by进行优化呢？
试想一下，如果放到临时表的数据量特别大，我们能不能跳过从内存临时表不够用了转成磁盘临时表的步骤，而是告诉MySQL我的数据量很大，请你最开始就使用磁盘临时表。
在 group by 语句中加入 SQL_BIG_RESULT 这个提示（hint），就可以告诉优化器：这个语句涉及的数据量很大，请直接用磁盘临时表。
MySQL 的优化器一看，磁盘临时表是 B+ 树存储，存储效率不如数组来得高。所以，既然你告诉我数据量很大，那从磁盘空间考虑，还是直接用数组来存吧。
select SQL_BIG_RESULT id%100 as m, count(*) as c from t1 group by m;
- 初始化 sort_buffer，确定放入一个整型字段，记为 m；
- 扫描表 t1 的索引 a，依次取出里面的 id 值, 将 id%100 的值存入 sort_buffer 中；
- 扫描完成后，对 sort_buffer 的字段 m 做排序（如果 sort_buffer 内存不够用，就会利用磁盘临时文件辅助排序）；
- 排序完成后，就得到了一个有序数组。
# 小结
何时使用内存临时表
- 如果语句执行过程可以一边读数据，一边直接得到结果，是不需要额外内存的，否则就需要额外的内存，来保存中间结果；
- join_buffer 是无序数组，sort_buffer 是有序数组，临时表是二维表结构；
- 如果执行逻辑需要用到二维表特性，就会优先考虑使用临时表。union 需要用到唯一索引约束， group by 还需要用到另外一个字段来存累积计数。
group优化
- 如果对 group by 语句的结果没有排序要求，要在语句后面加 order by null；
- 尽量让 group by 过程用上表的索引，确认方法是 explain 结果里没有 Using temporary 和 Using filesort；
- 如果 group by 需要统计的数据量不大，尽量只使用内存临时表；也可以通过适当调大 tmp_table_size 参数，来避免用到磁盘临时表；
- 如果数据量实在太大，使用 SQL_BIG_RESULT 这个提示，来告诉优化器直接使用排序算法得到 group by 的结果。