Mysql數據庫百萬級記錄查詢分頁優化

不少的朋友在面試中會遇到這樣的問題，也有不少的項目在運營一段時間後也會遇到MYSQL查詢中變慢的一些瓶頸，今天這兒簡單的介紹下我經常使用的幾種查詢分頁的方法，我所知道的也無非就是索引、分表、子查詢偏移，因此要是有什麼不對或有更好的方法，歡迎你們留言討論。

效率分析關鍵詞：explain + SQL語句

一，最多見MYSQL最基本的分頁方式limit：

    select * from `table` order by id desc limit 0, 20

在中小數據量的狀況下，這樣的SQL足夠用了，惟一須要注意的問題就是確保使用了索引。隨着數據量的增長，頁數會愈來愈多,在數據慢慢增加的過程當中，可能就會出現limit 10000,20這樣的狀況，limit 10000,20的意思掃描知足條件的10020行，扔掉前面的10000行，返回最後的20行，問題就在這裏，若是是limit 100000,100，須要掃描100100行，在一個高併發的應用裏，每次查詢須要掃描超過10W行，性能確定大打折扣。

這種方式有幾個不足：較大的偏移(OFFSET)會增長結果集，小比例的低效分頁足夠產生磁盤I/O瓶頸，須要掃描的行多。

簡單的解決方法:不顯示記錄總數，沒用戶在意這個數字;不讓用戶訪問頁數比較大的記錄，重定向他們;避免count(*) ,不顯示總數，讓用戶經過「下一頁」來翻頁 ,緩存總數;單獨統計總數，在插入和刪除時遞增/遞減

二，第二種就是分表，計算HASH值，這兒不作介紹了，我目前也沒有在項目中真正使用過這種方法，還停留在理論層次;

三，第三種是偏移：

    SELECT * FROM `table` WHERE id <= (SELECT id FROM `table` ORDER BY id desc LIMIT ".($page-1)*$pagesize.", 1) ORDER BY id desc LIMIT $pagesize

或者

    select * FROM `table` AS t1 JOIN (SELECT id FROM `table` ORDER BY id desc LIMIT 900,1) AS t2 WHERE t1.id<=t2.id order by t1.id desc limit 5

原理就是記錄住當前頁id的最大值和最小值，計算跳轉頁面和當前頁相對偏移，因爲頁面相近，這個偏移量不會很大，這樣的話m值相對較小，大大減小掃 描的行數。其實傳統的limit m,n，相對的偏移一直是第一頁，這樣的話越翻到後面，效率越差，而上面給出的方法就沒有這樣的問題。

好比仍是SELECT * FROM `table` ORDER BY id DESC，按id降序分頁，每頁20條，當前是第10頁，當前頁條目id最大的是9527，最小的是9500，若是咱們只提供」上一頁」、」下一頁」這樣 的跳轉（不提供到第N頁的跳轉），那麼在處理」上一頁」的時候SQL語句能夠是：

    SELECT * FROM `table` WHERE id > 9527 ORDER BY id ASC LIMIT 20;

處理」下一頁」的時候SQL語句能夠是：

    SELECT * FROM `table` WHERE id < 9500 ORDER BY id DESC LIMIT 20;

無論翻多少頁，每次查詢只掃描20行。

缺點是隻能提供」上一頁」、」下一頁」的連接形式，可是我通常來講很是喜歡」<上一頁 1 2 3 4 5 6 7 8 9 下一頁>」這樣的連接方式，怎麼辦呢？

若是LIMIT m,n不可避免的話，要優化效率，只有儘量的讓m小一下，咱們擴展前面作法，仍是SELECT * FROM `table` ORDER BY id DESC，按id降序分頁，每頁20條，當前是第10頁，當前頁條目id最大的是9527，最小的是9500，好比要跳到第8頁，我看的SQL語句能夠這 樣寫：

    SELECT * FROM `table` WHERE id > 9527 ORDER BY id ASC LIMIT 20,20;

跳轉到第13頁：

    SELECT * FROM `table` WHERE id < 9500 ORDER BY id DESC LIMIT 40,20;

注意SQL語句裏面的ASC和DESC，若是是ASC取出來的結果，顯示的時候記得倒置一下。

 

總體來講在面對百萬級數據的時候若是使用上面第三種方法來優化，系統性能上是可以獲得很好的提高，在遇到複雜的查詢時也儘可能簡化，減小運算量。 同時也儘可能多的使用內存緩存，有條件的能夠考慮分表、分庫、陣列之類的大型解決方案了。