MySQL實戰45講學習筆記----隨機訊息
有一個隨機顯示單詞的功能，每個使用者的級別有一個單詞表，然後這個使用者每次訪問首頁的時候，都會隨機滾動顯示三個單詞。隨著單詞表變大，選單詞這個邏輯變得越來越慢，甚至影響到了首頁的開啟速度。
表的建表語句和初始資料的命令如下：
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();
為了便於量化說明在這個表裡面插入了10000行記錄。
記憶體臨時表
首先，用order by rand()來實現這個邏輯。
mysql> select word from words order by rand() limit 3;
這個語句的意思很直白，隨機排序取前3個。雖然這個SQL語句寫法很簡單，但執行流程卻有點複雜的。
用explain命令來看看這個語句的執行情況。
圖1 使用explain命令檢視語句的執行情況
Extra欄位顯示Using temporary，表示的是需要使用臨時表；Using filesort，表示的是需要執行排序操作。
因此這個Extra的意思就是，需要臨時表，並且需要在臨時表上排序。
圖2 全欄位排序 圖3 rowid排序
對於InnoDB表來說，執行全欄位排序會減少磁碟訪問，因此會被優先選擇。
對於記憶體表，回表過程只是簡單地根據資料行的位置，直接訪問記憶體得到資料，根本不會導致多訪問磁碟。
優化器沒有了這一層顧慮，那麼它會優先考慮的，就是用於排序的行越少越好了，所以，MySQL這時就會選擇rowid排序。
理解了這個演算法選擇的邏輯，我們再來看看語句的執行流程。同時，通過今天的這個例子，我們來嘗試分析一下語句的掃描行數。
這條語句的執行流程是這樣的：
-
建立一個臨時表。這個臨時表使用的是memory引擎，表裡有兩個欄位，第一個欄位是double型別，為了後面描述方便，記為欄位R，第二個欄位是varchar(64)型別，記為欄位W。並且，這個表沒有建索引。
-
從words表中，按主鍵順序取出所有的word值。對於每一個word值，呼叫rand()函式生成一個大於0小於1的隨機小數，並把這個隨機小數和word分別存入臨時表的R和W欄位中，到此，掃描行數是10000。
-
現在臨時表有10000行資料了，接下來你要在這個沒有索引的記憶體臨時表上，按照欄位R排序。
-
初始化 sort_buffer。sort_buffer中有兩個欄位，一個是double型別，另一個是整型。
-
從記憶體臨時表中一行一行地取出R值和位置資訊（我後面會和你解釋這裡為什麼是“位置資訊”），分別存入sort_buffer中的兩個欄位裡。這個過程要對記憶體臨時表做全表掃描，此時掃描行數增加10000，變成了20000。
-
在sort_buffer中根據R的值進行排序。注意，這個過程沒有涉及到表操作，所以不會增加掃描行數。
-
排序完成後，取出前三個結果的位置資訊，依次到記憶體臨時表中取出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就是位置資訊，一個基本概念：MySQL的表是用什麼方法來定位“一行資料”的。
如果你建立的表沒有主鍵，或者把一個表的主鍵刪掉了，那麼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行也是有序的了。但，我們的查詢並不需要這些資料是有序的。所以，想一下就明白了，這浪費了非常多的計算量。
而優先佇列演算法，就可以精確地只得到三個最小值，執行流程如下：
- 對於這10000個準備排序的(R,rowid)，先取前三行，構造成一個堆；取下一個行(R’,rowid’)，跟當前堆裡面最大的R比較，如果R’小於R，把這個(R,rowid)從堆中去掉，換成(R’,rowid’)；
-
重複第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值，可以怎麼做呢？思路上是這樣的：
-
取得這個表的主鍵id的最大值M和最小值N;
-
用隨機函式生成一個最大值到最小值之間的數 X = (M-N)*rand() + N;
-
取不小於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，分別是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()比起來，執行代價還是小很多的。
現在，我們再看看，如果我們按照隨機演算法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；
上面的隨機演算法3的總掃描行數是 C+(Y1+1)+(Y2+1)+(Y3+1)，實際上它還是可以繼續優化，來進一步減少掃描行數的。
取Y1、Y2和Y3裡面最大的一個數，記為M，最小的一個數記為N，然後執行下面這條SQL語句：
mysql> select * from t limit N,M-N+1;
再加上取整個表總行數的C行，這個方案的掃描行數總共只需要C+M+1行。
當然也可以先取回id值，在應用中確定了三個id值以後，再執行三次where id=X的語句也是可以的。
感覺當資料量過大時，sql語句需要好好思考，並不是越複雜越好。資料結構和演算法的重要性，底層全靠這些在支撐。