一、本節概況
今天是大年初二，在開始我們今天的學習之前，我要先和你道一聲春節快樂！
在第 16和第 34篇文章中，我分別和你介紹了 sort buffer、內存臨時表和 join buffer。這三個數據結構都是用來存放語句執行過程中的中間數據，以輔助 SQL 語句的執行的。其
中，我們在排序的時候用到了 sort buffer，在使用 join 語句的時候用到了 join buffer。
然后，你可能會有這樣的疑問，MySQL 什么時候會使用內部臨時表呢？
今天這篇文章，我就先給你舉兩個需要用到內部臨時表的例子，來看看內部臨時表是怎么工作的。然后，我們再來分析，什么情況下會使用內部臨時表。
二、union 執行流程
1、 union 語句 explain 結果
為了便於量化分析，我用下面的表 t1 來舉例。
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，它的語義是，取這兩個子查詢結果的並集。並集的意思就是這兩個集合加起來，重復的行只保留一行。
下圖是這個語句的 explain 結果。
圖 1 union 語句 explain 結果
可以看到：
- 第二行的 key=PRIMARY，說明第二個子句用到了索引 id。
- 第三行的 Extra 字段，表示在對子查詢的結果集做 union 的時候，使用了臨時表 (Usingtemporary)。
2、union 執行流程圖
這個語句的執行流程是這樣的：
1. 創建一個內存臨時表，這個臨時表只有一個整型字段 f，並且 f 是主鍵字段。
2. 執行第一個子查詢，得到 1000 這個值，並存入臨時表中。
3. 執行第二個子查詢：
- 拿到第一行 id=1000，試圖插入臨時表中。但由於 1000 這個值已經存在於臨時表了，違反了唯一性約束，所以插入失敗，然后繼續執行；
- 取到第二行 id=999，插入臨時表成功。
4. 從臨時表中按行取出數據，返回結果，並刪除臨時表，結果中包含兩行數據分別是1000 和 999。
這個過程的流程圖如下所示：
圖 2 union 執行流程
可以看到，這里的內存臨時表起到了暫存數據的作用，而且計算過程還用上了臨時表主鍵id 的唯一性約束，實現了 union 的語義。
3、union all 的 explain 結果
順便提一下，如果把上面這個語句中的 union 改成 union all 的話，就沒有了“去重”的語義。這樣執行的時候，就依次執行子查詢，得到的結果直接作為結果集的一部分，發給
客戶端。因此也就不需要臨時表了。
圖 3 union all 的 explain 結果
可以看到，第二行的 Extra 字段顯示的是 Using index，表示只使用了覆蓋索引，沒有用臨時表了。
三、group by 執行流程
1、group by 的 explain 結果
另外一個常見的使用臨時表的例子是 group by，我們來看一下這個語句：
select id%10 as m, count(*) as c from t1 group by m;
這個語句的邏輯是把表 t1 里的數據，按照 id%10 進行分組統計，並按照 m 的結果排序后輸出。它的 explain 結果如下：
圖 4 group by 的 explain 結果
在 Extra 字段里面，我們可以看到三個信息：
Using index，表示這個語句使用了覆蓋索引，選擇了索引 a，不需要回表；
Using temporary，表示使用了臨時表；
Using filesort，表示需要排序。
2、group by 執行流程
這個語句的執行流程是這樣的：
1. 創建內存臨時表，表里有兩個字段 m 和 c，主鍵是 m；
2. 掃描表 t1 的索引 a，依次取出葉子節點上的 id 值，計算 id%10 的結果，記為 x；
如果臨時表中沒有主鍵為 x 的行，就插入一個記錄 (x,1);
如果表中有主鍵為 x 的行，就將 x 這一行的 c 值加 1；
3. 遍歷完成后，再根據字段 m 做排序，得到結果集返回給客戶端。
這個流程的執行圖如下：
圖 5 group by 執行流程
圖中最后一步，對內存臨時表的排序，在第 17 篇文章中已經有過介紹，我把圖貼過來，方便你回顧。
3、內存臨時表排序流程
圖 6 內存臨時表排序流程
其中，臨時表的排序過程就是圖 6 中虛線框內的過程。
4、group by 執行結果
接下來，我們再看一下這條語句的執行結果：
圖 7 group by 執行結果
5、group + order by null 的結果（內存臨時表）
如果你的需求並不需要對結果進行排序，那你可以在 SQL 語句末尾增加 order by null，也就是改成：
select id%10 as m, count(*) as c from t1 group by m order by null;
這樣就跳過了最后排序的階段，直接從臨時表中取數據返回。返回的結果如圖 8 所示。
圖 8 group + order by null 的結果（內存臨時表）
由於表 t1 中的 id 值是從 1 開始的，因此返回的結果集中第一行是 id=1；掃描到 id=10的時候才插入 m=0 這一行，因此結果集里最后一行才是 m=0。
這個例子里由於臨時表只有 10 行，內存可以放得下，因此全程只使用了內存臨時表。但是，內存臨時表的大小是有限制的，參數 tmp_table_size 就是控制這個內存大小的，默認是 16M。
如果我執行下面這個語句序列：
set tmp_table_size=1024; select id%100 as m, count(*) as c from t1 group by m order by null limit 10;
把內存臨時表的大小限制為最大 1024 字節，並把語句改成 id % 100，這樣返回結果里有100 行數據。但是，這時的內存臨時表大小不夠存下這 100 行數據，也就是說，執行過程
中會發現內存臨時表大小到達了上限（1024 字節）。
6、group + order by null 的結果（磁盤臨時表）
那么，這時候就會把內存臨時表轉成磁盤臨時表，磁盤臨時表默認使用的引擎是InnoDB。 這時，返回的結果如圖 9 所示。
圖 9 group + order by null 的結果（磁盤臨時表）
如果這個表 t1 的數據量很大，很可能這個查詢需要的磁盤臨時表就會占用大量的磁盤空間。
四、group by 優化方法 -- 索引
1、group by 算法優化 - 有序輸入
可以看到，不論是使用內存臨時表還是磁盤臨時表，group by 邏輯都需要構造一個帶唯一索引的表，執行代價都是比較高的。如果表的數據量比較大，上面這個 group by 語句
執行起來就會很慢，我們有什么優化的方法呢？
要解決 group by 語句的優化問題，你可以先想一下這個問題：執行 group by 語句為什么需要臨時表？
group by 的語義邏輯，是統計不同的值出現的個數。但是，由於每一行的 id%100 的結果是無序的，所以我們就需要有一個臨時表，來記錄並統計結果。
那么，如果掃描過程中可以保證出現的數據是有序的，是不是就簡單了呢？
假設，現在有一個類似圖 10 的這么一個數據結構，我們來看看 group by 可以怎么做。
圖 10 group by 算法優化 - 有序輸入
可以看到，如果可以確保輸入的數據是有序的，那么計算 group by 的時候，就只需要從左到右，順序掃描，依次累加。也就是下面這個過程：
- 當碰到第一個 1 的時候，已經知道累積了 X 個 0，結果集里的第一行就是 (0,X);
- 當碰到第一個 2 的時候，已經知道累積了 Y 個 1，結果集里的第二行就是 (1,Y);
按照這個邏輯執行的話，掃描到整個輸入的數據結束，就可以拿到 group by 的結果，不需要臨時表，也不需要再額外排序
2、InnoDB 的索引，就可以滿足這個輸入有序的條件
你一定想到了，InnoDB 的索引，就可以滿足這個輸入有序的條件。
在 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);
這樣，索引 z 上的數據就是類似圖 10 這樣有序的了。上面的 group by 語句就可以改成：
select z, count(*) as c from t1 group by z;
3、group by 優化的 explain 結果
優化后的 group by 語句的 explain 結果，如下圖所示：
圖 11 group by 優化的 explain 結果
從 Extra 字段可以看到，這個語句的執行不再需要臨時表，也不需要排序了。
五、group by 優化方法 -- 直接排序
1、使用 SQL_BIG_RESULT 的執行流程
所以，如果可以通過加索引來完成 group by 邏輯就再好不過了。但是，如果碰上不適合創建索引的場景，我們還是要老老實實做排序的。那么，這時候的 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;
的執行流程就是這樣的：
1. 初始化 sort_buffer，確定放入一個整型字段，記為 m；
2. 掃描表 t1 的索引 a，依次取出里面的 id 值, 將 id%100 的值存入 sort_buffer 中；
3. 掃描完成后，對 sort_buffer 的字段 m 做排序（如果 sort_buffer 內存不夠用，就會利用磁盤臨時文件輔助排序）；
4. 排序完成后，就得到了一個有序數組。
根據有序數組，得到數組里面的不同值，以及每個值的出現次數。這一步的邏輯，你已經從前面的圖 10 中了解過了。
2、使用 SQL_BIG_RESULT 的 explain 結果
下面兩張圖分別是執行流程圖和執行 explain 命令得到的結果。
圖 12 使用 SQL_BIG_RESULT 的執行流程圖
圖 13 使用 SQL_BIG_RESULT 的 explain 結果
從 Extra 字段可以看到，這個語句的執行沒有再使用臨時表，而是直接用了排序算法。
基於上面的 union、union all 和 group by 語句的執行過程的分析，我們來回答文章開頭的問題：MySQL 什么時候會使用內部臨時表？
1. 如果語句執行過程可以一邊讀數據，一邊直接得到結果，是不需要額外內存的，否則就需要額外的內存，來保存中間結果；
2. join_buffer 是無序數組，sort_buffer 是有序數組，臨時表是二維表結構；
3. 如果執行邏輯需要用到二維表特性，就會優先考慮使用臨時表。比如我們的例子中，union 需要用到唯一索引約束， group by 還需要用到另外一個字段來存累積計數。
六、小結
通過今天這篇文章，我重點和你講了 group by 的幾種實現算法，從中可以總結一些使用的指導原則：
1. 如果對 group by 語句的結果沒有排序要求，要在語句后面加 order by null；
2. 盡量讓 group by 過程用上表的索引，確認方法是 explain 結果里沒有 Usingtemporary 和 Using filesort；
3. 如果 group by 需要統計的數據量不大，盡量只使用內存臨時表；也可以通過適當調大tmp_table_size 參數，來避免用到磁盤臨時表；
4. 如果數據量實在太大，使用 SQL_BIG_RESULT 這個提示，來告訴優化器直接使用排序算法得到 group by 的結果。
最后，我給你留下一個思考題吧。
文章中圖 8 和圖 9 都是 order by null，為什么圖 8 的返回結果里面，0 是在結果集的最后一行，而圖 9 的結果里面，0 是在結果集的第一行？
你可以把你的分析寫在留言區里，我會在下一篇文章和你討論這個問題。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一起閱讀。
七、上期問題時間
上期的問題是：為什么不能用 rename 修改臨時表的改名。
在實現上，執行 rename table 語句的時候，要求按照“庫名 / 表名.frm”的規則去磁盤找文件，但是臨時表在磁盤上的 frm 文件是放在 tmpdir 目錄下的，並且文件名的規則
是“#sql{進程 id}_{線程 id}_ 序列號.frm”，因此會報“找不到文件名”的錯誤。
評論區留言點贊板：
@poppy 同學，通過執行語句的報錯現象推測了這個實現過程。