【面經(jīng)】面試官:如何以高的效率從MySQL中隨機(jī)查詢(xún)一條記錄?
作者個(gè)人研發(fā)的在高并發(fā)場(chǎng)景下,提供的簡(jiǎn)單、穩(wěn)定、可擴(kuò)展的延遲消息隊(duì)列框架,具有精準(zhǔn)的定時(shí)任務(wù)和延遲隊(duì)列處理功能。自開(kāi)源半年多以來(lái),已成功為十幾家中小型企業(yè)提供了精準(zhǔn)定時(shí)調(diào)度方案,經(jīng)受住了生產(chǎn)環(huán)境的考驗(yàn)。為使更多童鞋受益,現(xiàn)給出開(kāi)源框架地址:https://github.com/sunshinelyz/mykit-delay
寫(xiě)在前面
MySQL數(shù)據(jù)庫(kù)在互聯(lián)網(wǎng)行業(yè)使用的比較多,有些小伙伴可能會(huì)認(rèn)為MySQL數(shù)據(jù)庫(kù)比較小,存儲(chǔ)不了很多的數(shù)據(jù)。其實(shí),這些小伙伴是真的不了解MySQL。MySQL的小不是說(shuō)使用MySQL存儲(chǔ)的數(shù)據(jù)少,而是說(shuō)其體積小,比較輕量。使用MySQL完全可以存儲(chǔ)千億級(jí)別的數(shù)據(jù),這個(gè)我會(huì)在后面的文章中來(lái)給小伙伴們分享如何使用MySQL存儲(chǔ)千億級(jí)別以上的數(shù)據(jù)?;蛘咝』锇閭兛梢蕴崆邦A(yù)定我的新書(shū)《MySQL技術(shù)大全:開(kāi)發(fā)、優(yōu)化與運(yùn)維實(shí)戰(zhàn)》。好了,說(shuō)了這么多,今天給大家分享一篇有關(guān)MySQL的經(jīng)典面試題:如何以最高的效率從MySQL中隨機(jī)查詢(xún)一條記錄?
面試題目
如何從MySQL一個(gè)數(shù)據(jù)表中查詢(xún)一條隨機(jī)的記錄,同時(shí)要保證效率最高。
從這個(gè)題目來(lái)看,其實(shí)包含了兩個(gè)要求,第一個(gè)要求就是:從MySQL數(shù)據(jù)表中查詢(xún)一條隨機(jī)的記錄。第二個(gè)要求就是要保證效率最高。
接下來(lái),我們就來(lái)嘗試使用各種方式來(lái)從MySQL數(shù)據(jù)表中查詢(xún)數(shù)據(jù)。
方法一
這是最原始最直觀的語(yǔ)法,如下:
- SELECT * FROM foo ORDER BY RAND() LIMIT 1
當(dāng)數(shù)據(jù)表中數(shù)據(jù)量較小時(shí),此方法可行。但當(dāng)數(shù)據(jù)量到達(dá)一定程度,比如100萬(wàn)數(shù)據(jù)或以上,就有很大的性能問(wèn)題。如果你通過(guò)EXPLAIN來(lái)分析這個(gè) 語(yǔ)句,會(huì)發(fā)現(xiàn)雖然MySQL通過(guò)建立一張臨時(shí)表來(lái)排序,但由于ORDER BY和LIMIT本身的特性,在排序未完成之前,我們還是無(wú)法通過(guò)LIMIT來(lái)獲取需要的記錄。亦即,你的記錄有多少條,就必須首先對(duì)這些數(shù)據(jù)進(jìn)行排序。
方法二
看來(lái)對(duì)于大數(shù)據(jù)量的隨機(jī)數(shù)據(jù)抽取,性能的癥結(jié)出在ORDER BY上,那么如何避免?方法二提供了一個(gè)方案。
首先,獲取數(shù)據(jù)表的所有記錄數(shù):
- SELECT count(*) AS num_rows FROM foo
然后,通過(guò)對(duì)應(yīng)的后臺(tái)程序記錄下此記錄總數(shù)(假定為num_rows)。
然后執(zhí)行:
- SELECT * FROM foo LIMIT [0到num_rows之間的一個(gè)隨機(jī)數(shù)],1
上面這個(gè)隨機(jī)數(shù)的獲得可以通過(guò)后臺(tái)程序來(lái)完成。此方法的前提是表的ID是連續(xù)的或者自增長(zhǎng)的。
這個(gè)方法已經(jīng)成功避免了ORDER BY的產(chǎn)生。
方法三
有沒(méi)有可能不用ORDER BY,用一個(gè)SQL語(yǔ)句實(shí)現(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;
此方法實(shí)現(xiàn)了我們的目的,同時(shí),在數(shù)據(jù)量大的情況下,也避免了ORDER BY所造成的所有記錄的排序過(guò)程,因?yàn)橥ㄟ^(guò)JOIN里面的SELECT語(yǔ)句實(shí)際上只執(zhí)行了一次,而不是N次(N等于方法二中的num_rows)。而且, 我們可以在篩選語(yǔ)句上加上“大于”符號(hào),還可以避免因?yàn)镮D好不連續(xù)所產(chǎn)生的記錄為空的現(xiàn)象。
在MySQL中查詢(xún)5條不重復(fù)的數(shù)據(jù),使用以下:
- SELECT * FROM `table` ORDER BY RAND() LIMIT 5
就可以了。但是真正測(cè)試一下才發(fā)現(xiàn)這樣效率非常低。一個(gè)15萬(wàn)余條的庫(kù),查詢(xún)5條數(shù)據(jù),居然要8秒以上
搜索Google,網(wǎng)上基本上都是查詢(xún)max(id) * rand()來(lái)隨機(jī)獲取數(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;
但是這樣會(huì)產(chǎn)生連續(xù)的5條記錄。解決辦法只能是每次查詢(xún)一條,查詢(xún)5次。即便如此也值得,因?yàn)?5萬(wàn)條的表,查詢(xún)只需要0.01秒不到。
上面的語(yǔ)句采用的是JOIN,mysql的論壇上有人使用
- SELECT *
- FROM `table`
- WHERE id >= (SELECT FLOOR( MAX(id) * RAND()) FROM `table` )
- ORDER BY id LIMIT 1;
我測(cè)試了一下,需要0.5秒,速度也不錯(cuò),但是跟上面的語(yǔ)句還是有很大差距。總覺(jué)有什么地方不正常。
于是我把語(yǔ)句改寫(xiě)了一下。
- SELECT * FROM `table`
- WHERE id >= (SELECT floor(RAND() * (SELECT MAX(id) FROM `table`)))
- ORDER BY id LIMIT 1;
這下,效率又提高了,查詢(xún)時(shí)間只有0.01秒
最后,再把語(yǔ)句完善一下,加上MIN(id)的判斷。我在最開(kāi)始測(cè)試的時(shí)候,就是因?yàn)闆](méi)有加上MIN(id)的判斷,結(jié)果有一半的時(shí)間總是查詢(xún)到表中的前面幾行。
完整查詢(xún)語(yǔ)句是:
- 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;
最后對(duì)這兩個(gè)語(yǔ)句進(jìn)行分別查詢(xún)10次,
前者花費(fèi)時(shí)間 0.147433 秒,后者花費(fèi)時(shí)間 0.015130 秒
看來(lái)采用JOIN的語(yǔ)法比直接在WHERE中使用函數(shù)效率還要高很多。
本文轉(zhuǎn)載自微信公眾號(hào)「冰河技術(shù)」,可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系冰河技術(shù)公眾號(hào)。