寫在前面
MySQL數(shù)據(jù)庫在互聯(lián)網(wǎng)行業(yè)使用的比較多，有些小伙伴可能會認為MySQL數(shù)據(jù)庫比較小，存儲不了很多的數(shù)據(jù)。其實，這些小伙伴是真的不了解MySQL。MySQL的小不是說使用MySQL存儲的數(shù)據(jù)少，而是說其體積小，比較輕量。使用MySQL完全可以存儲千億級別的數(shù)據(jù)，這個我會在后面的文章中來給小伙伴們分享如何使用MySQL存儲千億級別以上的數(shù)據(jù)。或者小伙伴們可以提前預定我的新書《MySQL技術(shù)大全：開發(fā)、優(yōu)化與運維實戰(zhàn)》。好了，說了這么多，今天給大家分享一篇有關(guān)MySQL的經(jīng)典面試題：如何以最高的效率從MySQL中隨機查詢一條記錄？
方法一
這是最原始最直觀的語法，如下：
SELECT * FROM foo ORDER BY RAND() LIMIT 1
當數(shù)據(jù)表中數(shù)據(jù)量較小時，此方法可行。但當數(shù)據(jù)量到達一定程度，比如100萬數(shù)據(jù)或以上，就有很大的性能問題。如果你通過EXPLAIN來分析這個 語句，會發(fā)現(xiàn)雖然MySQL通過建立一張臨時表來排序，但由于ORDER BY和LIMIT本身的特性，在排序未完成之前，我們還是無法通過LIMIT來獲取需要的記錄。亦即，你的記錄有多少條，就必須首先對這些數(shù)據(jù)進行排序。
方法二
看來對于大數(shù)據(jù)量的隨機數(shù)據(jù)抽取，性能的癥結(jié)出在ORDER BY上，那么如何避免？方法二提供了一個方案。
首先，獲取數(shù)據(jù)表的所有記錄數(shù)：
SELECT count(*) AS num_rows FROM foo
然后，通過對應的后臺程序記錄下此記錄總數(shù)（假定為num_rows）。
然后執(zhí)行：
SELECT * FROM foo LIMIT [0到num_rows之間的一個隨機數(shù)],1
上面這個隨機數(shù)的獲得可以通過后臺程序來完成。此方法的前提是表的ID是連續(xù)的或者自增長的。
這個方法已經(jīng)成功避免了ORDER BY的產(chǎn)生。
方法三
有沒有可能不用ORDER BY，用一個SQL語句實現(xiàn)方法二？可以，那就是用JOIN。
SELECT * FROM Bar B JOIN (SELECT CEIL(MAX(ID)*RAND()) AS ID FROM Bar) AS m ON B.ID >= m.ID LIMIT 1;
此方法實現(xiàn)了我們的目的，同時，在數(shù)據(jù)量大的情況下，也避免了ORDER BY所造成的所有記錄的排序過程，因為通過JOIN里面的SELECT語句實際上只執(zhí)行了一次，而不是N次（N等于方法二中的num_rows）。而且， 我們可以在篩選語句上加上“大于”符號，還可以避免因為ID好不連續(xù)所產(chǎn)生的記錄為空的現(xiàn)象。
在MySQL中查詢5條不重復的數(shù)據(jù)，使用以下：
SELECT * FROM `table` ORDER BY RAND() LIMIT 5
就可以了。但是真正測試一下才發(fā)現(xiàn)這樣效率非常低。一個15萬余條的庫，查詢5條數(shù)據(jù)，居然要8秒以上
搜索google，網(wǎng)上基本上都是查詢max(id) * rand()來隨機獲取數(shù)據(jù)。
SELECT *
FROM `table` AS t1 JOIN (SELECT ROUND(RAND() * (SELECT MAX(id) FROM `table`)) AS id) AS t2
WHERE t1.id >= t2.id
ORDER BY t1.id ASC LIMIT 5;
但是這樣會產(chǎn)生連續(xù)的5條記錄。解決辦法只能是每次查詢一條，查詢5次。即便如此也值得，因為15萬條的表，查詢只需要0.01秒不到。
上面的語句采用的是JOIN，mysql的論壇上有人使用
SELECT *
FROM `table`
WHERE id >= (SELECT FLOOR( MAX(id) * RAND()) FROM `table` )
ORDER BY id LIMIT 1;
我測試了一下，需要0.5秒，速度也不錯，但是跟上面的語句還是有很大差距。總覺有什么地方不正常。
于是我把語句改寫了一下。
SELECT * FROM `table`
WHERE id >= (SELECT floor(RAND() * (SELECT MAX(id) FROM `table`)))
ORDER BY id LIMIT 1;
這下，效率又提高了，查詢時間只有0.01秒
最后，再把語句完善一下，加上MIN(id)的判斷。我在最開始測試的時候，就是因為沒有加上MIN(id)的判斷，結(jié)果有一半的時間總是查詢到表中的前面幾行。
完整查詢語句是：
SELECT * FROM `table`
WHERE id >= (SELECT floor( RAND() * ((SELECT MAX(id) FROM `table`)-(SELECT MIN(id) FROM `table`)) + (SELECT MIN(id) FROM `table`)))
ORDER BY id LIMIT 1;
SELECT *
FROM `table` AS t1 JOIN (SELECT ROUND(RAND() * ((SELECT MAX(id) FROM `table`)-(SELECT MIN(id) FROM `table`))+(SELECT MIN(id) FROM `table`)) AS id) AS t2
WHERE t1.id >= t2.id
ORDER BY t1.id LIMIT 1;
最后對這兩個語句進行分別查詢10次，
前者花費時間 0.147433 秒，后者花費時間 0.015130 秒
看來采用JOIN的語法比直接在WHERE中使用函數(shù)效率還要高很多。
重磅福利
微信搜一搜【冰河技術(shù)】微信公眾號，關(guān)注這個有深度的程序員，每天閱讀超硬核技術(shù)干貨，公眾號內(nèi)回復【PDF】有我準備的一線大廠面試資料和我原創(chuàng)的超硬核PDF技術(shù)文檔，以及我為大家精心準備的多套簡歷模板（不斷更新中），希望大家都能找到心儀的工作，學習是一條時而郁郁寡歡，時而開懷大笑的路，加油。如果你通過努力成功進入到了心儀的公司，一定不要懈怠放松，職場成長和新技術(shù)學習一樣，不進則退。如果有幸我們江湖再見！
另外，我開源的各個PDF，后續(xù)我都會持續(xù)更新和維護，感謝大家長期以來對冰河的支持！！
寫在最后
如果你覺得冰河寫的還不錯，請微信搜索并關(guān)注「 冰河技術(shù) 」微信公眾號，跟冰河學習高并發(fā)、分布式、微服務、大數(shù)據(jù)、互聯(lián)網(wǎng)和云原生技術(shù)，「 冰河技術(shù) 」微信公眾號更新了大量技術(shù)專題，每一篇技術(shù)文章干貨滿滿！不少讀者已經(jīng)通過閱讀「 冰河技術(shù) 」微信公眾號文章，吊打面試官，成功跳槽到大廠；也有不少讀者實現(xiàn)了技術(shù)上的飛躍，成為公司的技術(shù)骨干！如果你也想像他們一樣提升自己的能力，實現(xiàn)技術(shù)能力的飛躍，進大廠，升職加薪，那就關(guān)注「 冰河技術(shù) 」微信公眾號吧，每天更新超硬核技術(shù)干貨，讓你對如何提升技術(shù)能力不再迷茫！
