17 | 如何正確地顯示隨機消息？

我在上一篇文章，爲你講解完order by語句的幾種執行模式後，就想到了以前一個作英語學習App的朋友碰到過的一個性能問題。今天這篇文章，我就從這個性能問題提及，和你說說MySQL中的另一種排序需求，但願可以加深你對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行記錄。接下來，咱們就一塊兒看看要隨機選擇3個單詞，有什麼方法實現，存在什麼問題以及如何改進。

內存臨時表

首先，你會想到用order by rand()來實現這個邏輯。

mysql> select word from words order by rand() limit 3;

這個語句的意思很直白，隨機排序取前3個。雖然這個SQL語句寫法很簡單，但執行流程卻有點複雜的。

咱們先用explain命令來看看這個語句的執行狀況。

圖1 使用explain命令查看語句的執行狀況

Extra字段顯示Using temporary，表示的是須要使用臨時表；Using filesort，表示的是須要執行排序操做。

所以這個Extra的意思就是，須要臨時表，而且須要在臨時表上排序。

這裏，你能夠先回顧一下上一篇文章中全字段排序和rowid排序的內容。我把上一篇文章的兩個流程圖貼過來，方便你複習。

圖2 全字段排序

圖3 rowid排序

而後，我再問你一個問題，你以爲對於臨時內存表的排序來講，它會選擇哪種算法呢？回顧一下上一篇文章的一個結論：對於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行，也就驗證了咱們分析得出的結論。

這裏插一句題外話，在平時學習概念的過程當中，你能夠常常這樣作，先經過原理分析算出掃描行數，而後再經過查看慢查詢日誌，來驗證本身的結論。我本身就是常常這麼作，這個過程頗有趣，分析對了開心，分析錯了可是弄清楚了也很開心。

如今，我來把完整的排序執行流程圖畫出來。

圖4 隨機排序完整流程圖1

圖中的pos就是位置信息，你可能會以爲奇怪，這裏的「位置信息」是個什麼概念？在上一篇文章中，咱們對InnoDB表排序的時候，明明用的仍是ID字段。

這時候，咱們就要回到一個基本概念：MySQL的表是用什麼方法來定位「一行數據」的。

在前面第4和第5篇介紹索引的文章中，有幾位同窗問到，若是把一個InnoDB表的主鍵刪掉，是否是就沒有主鍵，就沒辦法回表了？

其實不是的。若是你建立的表沒有主鍵，或者把一個表的主鍵刪掉了，那麼InnoDB會本身生成一個長度爲6字節的rowid來做爲主鍵。

這也就是排序模式裏面，rowid名字的來歷。實際上它表示的是：每一個引擎用來惟一標識數據行的信息。

• 對於有主鍵的InnoDB表來講，這個rowid就是主鍵ID；
• 對於沒有主鍵的InnoDB表來講，這個rowid就是由系統生成的；
• MEMORY引擎不是索引組織表。在這個例子裏面，你能夠認爲它就是一個數組。所以，這個rowid其實就是數組的下標。

到這裏，我來稍微小結一下：order by rand()使用了內存臨時表，內存臨時表排序的時候使用了rowid排序方法。

磁盤臨時表

那麼，是否是全部的臨時表都是內存表呢？

其實不是的。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

圖5 OPTIMIZER_TRACE部分結果

而後，咱們來看一下此次OPTIMIZER_TRACE的結果。

由於將max_length_for_sort_data設置成16，小於word字段的長度定義，因此咱們看到sort_mode裏面顯示的是rowid排序，這個是符合預期的，參與排序的是隨機值R字段和rowid字段組成的行。

這時候你可能心算了一下，發現不對。R字段存放的隨機值就8個字節，rowid是6個字節（至於爲何是6字節，就留給你課後思考吧），數據總行數是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)，先取前三行，構形成一個堆；

（對數據結構印象模糊的同窗，能夠先設想成這是一個由三個元素組成的數組）

1. 取下一個行(R’,rowid’)，跟當前堆裏面最大的R比較，若是R’小於R，把這個(R,rowid)從堆中去掉，換成(R’,rowid’)；

2. 重複第2步，直到第10000個(R’,rowid’)完成比較。

這裏我簡單畫了一個優先隊列排序過程的示意圖。

圖6 優先隊列排序算法示例

圖6是模擬6個(R,rowid)行，經過優先隊列排序找到最小的三個R值的行的過程。整個排序過程當中，爲了最快地拿到當前堆的最大值，老是保持最大值在堆頂，所以這是一個最大堆。

圖5的OPTIMIZER_TRACE結果中，filesort_priority_queue_optimization這個部分的chosen=true，就表示使用了優先隊列排序算法，這個過程不須要臨時文件，所以對應的number_of_tmp_files是0。

這個流程結束後，咱們構造的堆裏面，就是這個10000行裏面R值最小的三行。而後，依次把它們的rowid取出來，去臨時表裏面拿到word字段，這個過程就跟上一篇文章的rowid排序的過程同樣了。

咱們再看一下上面一篇文章的SQL查詢語句：

select city,name,age from t where city='杭州' order by name limit 1000 ;

你可能會問，這裏也用到了limit，爲何沒用優先隊列排序算法呢？緣由是，這條SQL語句是limit 1000，若是使用優先隊列算法的話，須要維護的堆的大小就是1000行的(name,rowid)，超過了我設置的sort_buffer_size大小，因此只能使用歸併排序算法。

總之，不管是使用哪一種類型的臨時表，order by rand()這種寫法都會讓計算過程很是複雜，須要大量的掃描行數，所以排序過程的資源消耗也會很大。

再回到咱們文章開頭的問題，怎麼正確地隨機排序呢？

隨機排序方法

咱們先把問題簡化一下，若是隻隨機選擇1個word值，能夠怎麼作呢？思路上是這樣的：

1. 取得這個表的主鍵id的最大值M和最小值N;

2. 用隨機函數生成一個最大值到最小值之間的數 X = (M-N)*rand() + N;

3. 取不小於X的第一個ID的行。

咱們把這個算法，暫時稱做隨機算法1。這裏，我直接給你貼一下執行語句的序列:

mysql> select max(id),min(id) into @M,@N from t ;
set @X= floor((@M-@N+1)*rand() + @N);
select * from t where id >= @X limit 1;

這個方法效率很高，由於取max(id)和min(id)都是不須要掃描索引的，而第三步的select也能夠用索引快速定位，能夠認爲就只掃描了3行。但實際上，這個算法自己並不嚴格知足題目的隨機要求，由於ID中間可能有空洞，所以選擇不一樣行的機率不同，不是真正的隨機。

好比你有4個id，分別是一、二、四、5，若是按照上面的方法，那麼取到 id=4的這一行的機率是取得其餘行機率的兩倍。

若是這四行的id分別是一、二、40000、40001呢？這個算法基本就能當bug來看待了。

因此，爲了獲得嚴格隨機的結果，你能夠用下面這個流程:

1. 取得整個表的行數，並記爲C。

2. 取得 Y = floor(C * rand())。 floor函數在這裏的做用，就是取整數部分。

3. 再用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值呢？你能夠這麼作：

1. 取得整個表的行數，記爲C；

2. 根據相同的隨機方法獲得Y一、Y二、Y3；

3. 再執行三個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； //在應用代碼裏面取Y一、Y二、Y3值，拼出SQL後執行
select * from t limit @Y2，1；
select * from t limit @Y3，1；

小結

今天這篇文章，我是藉着隨機排序的需求，跟你介紹了MySQL對臨時表排序的執行過程。

若是你直接使用order by rand()，這個語句須要Using temporary 和 Using filesort，查詢的執行代價每每是比較大的。因此，在設計的時候你要量避開這種寫法。

今天的例子裏面，咱們不是僅僅在數據庫內部解決問題，還會讓應用代碼配合拼接SQL語句。在實際應用的過程當中，比較規範的用法就是：儘可能將業務邏輯寫在業務代碼中，讓數據庫只作「讀寫數據」的事情。所以，這類方法的應用仍是比較普遍的。

最後，我給你留下一個思考題吧。

上面的隨機算法3的總掃描行數是 C+(Y1+1)+(Y2+1)+(Y3+1)，實際上它仍是能夠繼續優化，來進一步減小掃描行數的。

個人問題是，若是你是這個需求的開發人員，你會怎麼作，來減小掃描行數呢？說說你的方案，並說明你的方案須要的掃描行數。

你能夠把你的設計和結論寫在留言區裏，我會在下一篇文章的末尾和你討論這個問題。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一塊兒閱讀。

上期問題時間

我在上一篇文章最後留給你的問題是，select * from t where city in (「杭州」," 蘇州 ") order by name limit 100;這個SQL語句是否須要排序？有什麼方案能夠避免排序？

雖然有(city,name)聯合索引，對於單個city內部，name是遞增的。可是因爲這條SQL語句不是要單獨地查一個city的值，而是同時查了"杭州"和" 蘇州 "兩個城市，所以全部知足條件的name就不是遞增的了。也就是說，這條SQL語句須要排序。

那怎麼避免排序呢？

這裏，咱們要用到(city,name)聯合索引的特性，把這一條語句拆成兩條語句，執行流程以下：

1. 執行select * from t where city=「杭州」 order by name limit 100; 這個語句是不須要排序的，客戶端用一個長度爲100的內存數組A保存結果。

2. 執行select * from t where city=「蘇州」 order by name limit 100; 用相同的方法，假設結果被存進了內存數組B。

3. 如今A和B是兩個有序數組，而後你能夠用歸併排序的思想，獲得name最小的前100值，就是咱們須要的結果了。

若是把這條SQL語句裏「limit 100」改爲「limit 10000,100」的話，處理方式其實也差很少，即：要把上面的兩條語句改爲寫：

select * from t where city="杭州" order by name limit 10100;

和

select * from t where city="蘇州" order by name limit 10100。

這時候數據量較大，能夠同時起兩個鏈接一行行讀結果，用歸併排序算法拿到這兩個結果集裏，按順序取第10001~10100的name值，就是須要的結果了。

固然這個方案有一個明顯的損失，就是從數據庫返回給客戶端的數據量變大了。

因此，若是數據的單行比較大的話，能夠考慮把這兩條SQL語句改爲下面這種寫法：

select id,name from t where city="杭州" order by name limit 10100;

和

select id,name from t where city="蘇州" order by name limit 10100。

而後，再用歸併排序的方法取得按name順序第10001~10100的name、id的值，而後拿着這100個id到數據庫中去查出全部記錄。

上面這些方法，須要你根據性能需求和開發的複雜度作出權衡。