首頁  >  文章  >  資料庫  >  總結MySQL的分頁技術

總結MySQL的分頁技術

巴扎黑
巴扎黑原創
2017-05-01 13:48:091293瀏覽

  有朋友問: MySQL的分頁似乎一直是個問題,有什麼最佳化方法嗎?網路上看到網路上推薦了一些分頁方法,但似乎不太可行,可以點評一下嗎?

  方法1: 直接使用資料庫提供的SQL語句

#   ---語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N。

  ---適應場景: 適用於資料量較少的情況(元組百/千級)。

  ---原因/缺點: 全表掃描,速度會很慢 且 有的資料庫結果集返回不穩定(如某次返回1,2,3,另外的一次返回2,1,3)。 Limit限制的是從結果集的M位置處取出N條輸出,其餘拋棄。

  方法2: 建立主鍵或唯一索引, 利用索引(假設每頁10條)

#   ---語句樣式: MySQL中,可用以下方法: 

#   SELECT * FROM 表名稱 WHERE id_pk > (pageNum*10) LIMIT M。

  ---適應場景: 適用於資料量多的情況(元組數上萬)。

  ---原因: 索引掃描,速度會很快。有朋友提出因為資料查詢出來並不是依照pk_id排序的,所以會有漏掉資料的情況,只能方法3。

  方法3: 基於索引再排序

  ---語句樣式: MySQL中,可用以下方法: SELECT * FROM 表名稱 WHERE id_pk > (pageNum*10) ORDER BY id_pk ASC LIMIT M。

---適應場景: 適用於資料量多的情況(元組數上萬). 最好ORDER  BY後的列物件是主鍵或唯一所以,使得ORDERBY操作能利用索引被消除但結果集是穩定的(穩定的意義,參見方法1)。

  ---原因: 索引掃描,速度會很快. 但MySQL的排序操作,只有ASC沒有DESC(DESC是假的,未來會做真正的DESC,期待)。

  方法4: 基於索引使用prepare(第一個問號表示pageNum,第二個?表示每頁元組數)

#   ---語句樣式: MySQL中,可用以下方法: 

#   PREPARE stmt_name FROM SELECT * FROM 表名稱 WHERE id_pk > (?* ?) ORDER BY id_pk 

##   ASC LIMIT M。

  ---適應場景: 大數據量。

  ---原因: 索引掃描,速度會很快. prepare語句又比一般的查詢語句快一點。

  方法5:利用MySQL支援ORDER操作可以利用索引快速定位部分元組,避免全表掃描

#   ---例如: 讀第1000到1019行元組(pk是主鍵/唯一鍵)。

  ---SELECT * FROM your_table WHERE pk>=1000 ORDER BY pk ASC LIMIT 0,20。

  方法6: 利用"子查詢/連接+索引"快速定位元組的位置,然後再讀取元組.道理同方法5

#   ---如(id是主鍵/唯一鍵,藍色字體時變數):

#   利用子查詢範例:

SELECT * FROM your_table WHERE id <=
(SELECT id FROM your_table ORDER
BY id desc LIMIT ($page-1)*$pagesize ORDER BY id desc
LIMIT $pagesize

  利用連線範例:

SELECT * FROM your_table AS t1
JOIN (SELECT id FROM your_table ORDER BY
id desc LIMIT ($page-1)*$pagesize AS t2
WHERE
t1.id <= t2.id ORDER BY t1.id desc LIMIT $pagesize;

  方法7: 預存程序類別(最好融合上述方法5/6)

  ---語句樣式: 不再給出

#   ---適應場景: 大數據量.  #作者推薦的方法

#   ---原因: 把操作封裝在伺服器,相對更快一些。

  方法8: 反面方法

  ---網路上有人寫使用 SQL_CALC_FOUND_ROWS。 沒有道理,勿模仿 。

  基本上,可以推廣到所有資料庫,道理是一樣的。但方法5未必能推廣到其他資料庫,推廣的前提是,其他資料庫支援ORDER BY作業可以利用索引直接完成排序。

以上是總結MySQL的分頁技術的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn