MySQL的分頁技術總結

有朋友問: MySQL的分頁似乎一直是個問題，有什麼優化方法嗎？

網上看到趕集網XX推薦了一些分頁方法,但似乎不太可行，你能點評一下嗎？

=========================================

---方法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，第二個？表示每頁元組數）

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 $pagesize;

---方法7: 存儲過程類（最好融合上述方法5/6）

---語句樣式:

不再給出

---适應場景: 大資料量.  作者推薦的方法

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

---方法8: 反面方法

---網上有人寫使用

SQL_CALC_FOUND_ROWS。 沒有道理，勿模仿 

基本上,可以推廣到所有資料庫,道理是一樣的.但方法5未必能推廣到其他資料庫,推廣的前提是,其他資料庫支援ORDER

BY操作可以利用索引直接完成排序.

1.http://imysql.com/2014/07/26/mysql-optimization-case-paging-optimize.shtml

2.http://www.vmcd.org/2014/07/advance-for-mysql-pagination/