隨機(jī)獲得MySQL數(shù)據(jù)表的一條或多條記錄有很多方法，下面我就以u(píng)sers（userId，userName，password……）表（有一百多萬條記錄）為例，對(duì)比講解下幾個(gè)方法效率問題：
select * from users order by rand() LIMIT 1
執(zhí)行該sql語句，老半天沒有反應(yīng)，最后被迫手動(dòng)停止執(zhí)行，怎個(gè)傷人了得啊！后來我查了一下MYSQL手冊(cè)，里面針對(duì)RAND()的提示大概意思就是，在ORDER BY從句里面不能使用RAND()函數(shù)，因?yàn)檫@樣會(huì)導(dǎo)致數(shù)據(jù)列被多次掃描，導(dǎo)致效率相當(dāng)相當(dāng)?shù)牡停⌒什恍?，切忌使用?/p>SELECT * FROM users AS t1 JOIN (SELECT ROUND(RAND() * ((SELECT MAX(userId) FROM
users)-(SELECT MIN(userId) FROM users))+(SELECT MIN(userId) FROM users)) AS userId) AS t2 WHERE t1.userId >= t2.userId ORDER BY t1.userId LIMIT 1
執(zhí)行該sql語句，用時(shí)0.031s，效率沒說的，相當(dāng)?shù)慕o力！心里那個(gè)爽啊，緊接著，我把”LIMIT 1“改為了”LIMIT 100“ 隨機(jī)取一百條記錄，用時(shí)0.048，給力吧?？墒蔷驮诖藭r(shí)問題出現(xiàn)了，發(fā)現(xiàn)結(jié)果好像不是隨機(jī)的？為了驗(yàn)證結(jié)果，又執(zhí)行了N次，真不是隨機(jī)的， 問題出現(xiàn)在”O(jiān)RDER BY t1.userId“這里，按userId排序了。隨機(jī)取一條記錄還是不錯(cuò)的選擇，多條就不行了??！SELECT * FROM users WHERE userId >= ((SELECT MAX(userId) FROM users)-(SELECT MIN(userId) FROM users)) * RAND() + (SELECT MIN(userId) FROM users) LIMIT 1
執(zhí)行該sql語句，用時(shí)0.039s，效率太給力了！接著我就把”LIMIT 1“改為了”LIMIT 10000“，用時(shí)0.063s。經(jīng)過多次驗(yàn)證，哥對(duì)燈發(fā)誓，結(jié)果肯定是隨機(jī)的！
結(jié)論：隨機(jī)取一條或多條記錄，方法都不錯(cuò)！-
通過sql獲得最大值和最小值，然后通過php的rand生成一個(gè)隨機(jī)數(shù)randnum，再通過SELECT * FROM users WHERE userId >= randnum LIMIT 1，效率應(yīng)該差不多，
結(jié)論：方法1效率不行，切忌使用；隨機(jī)獲得一條記錄，方法2是相當(dāng)不錯(cuò)的選擇，采用JOIN的語法比直接在WHERE中使用函數(shù)效率還是要高一些的，不過方法3也不錯(cuò)；隨機(jī)獲得多條記錄，方法3沒說的！
方法札記
1 將數(shù)據(jù)庫中的記錄按照隨機(jī)數(shù)進(jìn)行排序，利用LIMIT取前面n條記錄即可。
SELECT * FROM news_tagging_app_tag as t ORDER BY rand() LIMIT 50;
附
該文章于2017年8月30日于CSDN上首次發(fā)表，2017年12月24日搬家至此！
