1、概念
MySQL的另外一種排序邏輯；
在英語APP首頁有一個隨機顯示單詞的功能，也就是根據每個用戶的級別有一個單詞表，然后這個用戶每次訪問首頁的時候，都會隨機滾動顯示三個單詞。他們發現隨着單詞表變大，選單詞這個邏輯變得越來越慢，甚至影響到了首頁的打開速度。
設計SQL語句應該如何進行設計呢？
mysql> CREATE TABLE `words` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`word` varchar(64) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
delimiter ;;
create procedure idata()
begin
declare i int;
set i=0;
while i<10000 do
insert into words(word) values(concat(char(97+(i div 1000)), char(97+(i % 1000 div 100)), char(97+(i % 100 div 10)), char(97+(i % 10))));
set i=i+1;
end while;
end;;
delimiter ;
call idata()
在這個表中插入1w行數據，接下來隨機選取三個，該如何設計呢？
2、內存臨時表
首先會想到使用orderby rand()實現這個邏輯
mysql> select word from words order by rand() limit 3;
這個語句邏輯寫法很簡單，但是語句執行情況卻是很復雜的。
Extra字段顯示Using temporary，表示的是需要使用臨時表；Using filesort，表示的是需要執行排序操作。
因此這個Extra的意思就是，需要臨時表，並且需要在臨時表上排序。
對於InnoDB表來說，執行全字段排序會減少磁盤訪問，因此會被優先選擇。
我強調了“InnoDB表”，你肯定想到了，對於內存表，回表過程只是簡單地根據數據行的位置，直接訪問內存得到數據，根本不會導致多訪問磁盤。優化器沒有了這一層顧慮，那么它會優先考慮的，就是用於排序的行越少越好了，所以，MySQL這時就會選擇rowid排序。
理解了這個算法選擇的邏輯，我們再來看看語句的執行流程。同時，通過今天的這個例子，我們來嘗試分析一下語句的掃描行數。
1）創建一個臨時表。這個臨時表使用的是memory引擎，表里有兩個字段，第一個字段是double類型，為了后面描述方便，記為字段R，第二個字段是varchar(64)類型，記為字段W。並且，這個表沒有建索引。
2）從words表中，按主鍵順序取出所有的word值。對於每一個word值，調用rand()函數生成一個大於0小於1的隨機小數，並把這個隨機小數和word分別存入臨時表的R和W字段中，到此，掃描行數是10000。
3）現在臨時表有10000行數據了，接下來你要在這個沒有索引的內存臨時表上，按照字段R排序。
4）初始化 sort_buffer。sort_buffer中有兩個字段，一個是double類型，另一個是整型。
5）從內存臨時表中一行一行地取出R值和位置信息（我后面會和你解釋這里為什么是“位置信息”），分別存入sort_buffer中的兩個字段里。這個過程要對內存臨時表做全表掃描，此時掃描行數增加10000，變成了20000。
6）在sort_buffer中根據R的值進行排序。注意，這個過程沒有涉及到表操作，所以不會增加掃描行數。
7）排序完成后，取出前三個結果的位置信息，依次到內存臨時表中取出word值，返回給客戶端。這個過程中，訪問了表的三行數據，總掃描行數變成了20003。
接下來，我們通過慢查詢日志（slow log）來驗證一下我們分析得到的掃描行數是否正確。
# Query_time: 0.900376 Lock_time: 0.000347 Rows_sent: 3 Rows_examined: 20003
SET timestamp=1541402277;
select word from words order by rand() limit 3;
其中，Rows_examined：20003就表示這個語句執行過程中掃描了20003行，也就驗證了我們分析得出的結論。
在平時學習概念的同時，先通過原理分析算出掃描行數，然后再通過查看慢查詢日志，來驗證自己的結論。
排序執行的流程圖：
MySQL的表是用什么方法來定位“一行數據”的。
order by rand()使用了內存臨時表，內存臨時表排序的時候使用了rowid排序方法。
3、磁盤臨時表
不是所有的臨時表都是內存表，tmp_table_size這個配置限制了內存臨時表的大小，默認值是16M。如果臨時表大小超過了tmp_table_size，那么內存臨時表就會轉成磁盤臨時表。
磁盤臨時表使用的引擎默認是InnoDB，是由參數internal_tmp_disk_storage_engine控制的。
當使用磁盤臨時表的時候，對應的就是一個沒有顯式索引的InnoDB表的排序過程。
為了復現這個過程，把tmp_table_size設置成1024，把sort_buffer_size設置成 32768, 把 max_length_for_sort_data 設置成16。
set tmp_table_size=1024;
set sort_buffer_size=32768;
set max_length_for_sort_data=16;
/* 打開 optimizer_trace，只對本線程有效 */
SET optimizer_trace='enabled=on';
/* 執行語句 */
select word from words order by rand() limit 3;
/* 查看 OPTIMIZER_TRACE 輸出 */
SELECT * FROM `information_schema`.`OPTIMIZER_TRACE`\G
因為將max_length_for_sort_data設置成16，小於word字段的長度定義，所以我們看到sort_mode里面顯示的是rowid排序，這個是符合預期的，參與排序的是隨機值R字段和rowid字段組成的行。
數據總行數是10000，這樣算出來就有140000字節，超過了sort_buffer_size 定義的 32768字節了。但是，number_of_tmp_files的值居然是0，難道不需要用臨時文件嗎？
這個SQL語句的排序確實沒有用到臨時文件，采用是MySQL 5.6版本引入的一個新的排序算法，即：優先隊列排序算法。接下來，我們就看看為什么沒有使用臨時文件的算法，也就是歸並排序算法，而是采用了優先隊列排序算法。
其實，我們現在的SQL語句，只需要取R值最小的3個rowid。但是，如果使用歸並排序算法的話，雖然最終也能得到前3個值，但是這個算法結束后，已經將10000行數據都排好序了。
也就是說，后面的9997行也是有序的了。但，我們的查詢並不需要這些數據是有序的。所以，想一下就明白了，這浪費了非常多的計算量。
而優先隊列算法，就可以精確地只得到三個最小值，執行流程如下：
1）對於這10000個准備排序的(R,rowid)，先取前三行，構造成一個堆；
（對數據結構印象模糊的同學，可以先設想成這是一個由三個元素組成的數組）
2）取下一個行(R’,rowid’)，跟當前堆里面最大的R比較，如果R’小於R，把這個(R,rowid)從堆中去掉，換成(R’,rowid’)；
3）重復第2步，直到第10000個(R’,rowid’)完成比較。
圖6是模擬6個(R,rowid)行，通過優先隊列排序找到最小的三個R值的行的過程。整個排序過程中，為了最快地拿到當前堆的最大值，總是保持最大值在堆頂，因此這是一個最大堆。
圖5的OPTIMIZER_TRACE結果中，filesort_priority_queue_optimization這個部分的chosen=true，就表示使用了優先隊列排序算法，這個過程不需要臨時文件，因此對應的number_of_tmp_files是0。
這個流程結束后，我們構造的堆里面，就是這個10000行里面R值最小的三行。然后，依次把它們的rowid取出來，去臨時表里面拿到word字段，這個過程就跟上一篇文章的rowid排序的過程一樣了。
4、隨機排序方法
如果只隨機選擇1個word值，可以怎么做呢？思路上是這樣的：
取得這個表的主鍵id的最大值M和最小值N;
用隨機函數生成一個最大值到最小值之間的數 X = (M-N)*rand() + N;
取不小於X的第一個ID的行。
我們把這個算法，暫時稱作隨機算法1。這里，我直接給你貼一下執行語句的序列:
這個方法效率很高，因為取max(id)和min(id)都是不需要掃描索引的，而第三步的select也可以用索引快速定位，可以認為就只掃描了3行。但實際上，這個算法本身並不嚴格滿足題目的隨機要求，因為ID中間可能有空洞，因此選擇不同行的概率不一樣，不是真正的隨機。
比如你有4個id，分別是1、2、4、5，如果按照上面的方法，那么取到 id=4的這一行的概率是取得其他行概率的兩倍。
如果這四行的id分別是1、2、40000、40001呢？這個算法基本就能當bug來看待了。
所以，為了得到嚴格隨機的結果，你可以用下面這個流程:
取得整個表的行數，並記為C。
取得 Y = floor(C * rand())。 floor函數在這里的作用，就是取整數部分。
再用limit Y,1 取得一行。
我們把這個算法，稱為隨機算法2。下面這段代碼，就是上面流程的執行語句的序列。
mysql> select count(*) into @C from t;
set @Y = floor(@C * rand());
set @sql = concat("select * from t limit ", @Y, ",1");
prepare stmt from @sql;
execute stmt;
DEALLOCATE prepare stmt;
由於limit 后面的參數不能直接跟變量，所以我在上面的代碼中使用了prepare+execute的方法。你也可以把拼接SQL語句的方法寫在應用程序中，會更簡單些。
這個隨機算法2，解決了算法1里面明顯的概率不均勻問題。
MySQL處理limit Y,1 的做法就是按順序一個一個地讀出來，丟掉前Y個，然后把下一個記錄作為返回結果，因此這一步需要掃描Y+1行。再加上，第一步掃描的C行，總共需要掃描C+Y+1行，執行代價比隨機算法1的代價要高。
當然，隨機算法2跟直接order by rand()比起來，執行代價還是小很多的。
你可能問了，如果按照這個表有10000行來計算的話，C=10000，要是隨機到比較大的Y值，那掃描行數也跟20000差不多了，接近order by rand()的掃描行數，為什么說隨機算法2的代價要小很多呢？我就把這個問題留給你去課后思考吧。
現在，我們再看看，如果我們按照隨機算法2的思路，要隨機取3個word值呢？你可以這么做：
- 取得整個表的行數，記為C；
- 根據相同的隨機方法得到Y1、Y2、Y3；
- 再執行三個limit Y, 1語句得到三行數據。
我們把這個算法，稱作隨機算法3。下面這段代碼，就是上面流程的執行語句的序列。
mysql> select count(*) into @C from t;
set @Y1 = floor(@C * rand());
set @Y2 = floor(@C * rand());
set @Y3 = floor(@C * rand());
select * from t limit @Y1，1； //在應用代碼里面取Y1、Y2、Y3值，拼出SQL后執行
select * from t limit @Y2，1；
select * from t limit @Y3，1；
5、小結
介紹了MySQL對臨時表排序的執行過程。
如果你直接使用order by rand()，這個語句需要Using temporary 和 Using filesort，查詢的執行代價往往是比較大的。所以，在設計的時候你要量避開這種寫法。
今天的例子里面，我們不是僅僅在數據庫內部解決問題，還會讓應用代碼配合拼接SQL語句。在實際應用的過程中，比較規范的用法就是：盡量將業務邏輯寫在業務代碼中，讓數據庫只做“讀寫數據”的事情。因此，這類方法的應用還是比較廣泛的。