8種MySQL分頁辦法總結。本站提示廣大學習愛好者：（8種MySQL分頁辦法總結）文章只能為提供參考，不一定能成為您想要的結果。以下是8種MySQL分頁辦法總結正文
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* FROMyour_table WHEREid <=
(SELECTid FROMyour_table ORDER
BYid descLIMIT ($page-1)*$pagesize ORDERBYid desc
LIMIT $pagesize
應用銜接示例:
SELECT* FROMyour_table ASt1
JOIN(SELECTid FROMyour_table ORDERBY
id descLIMIT ($page-1)*$pagesize ASt2
WHERE
t1.id <= t2.id ORDERBYt1.id descLIMIT $pagesize;
辦法7: 存儲進程類（最好融會上述辦法5/6）
---語句款式: 不再給出
---順應場景: 年夜數據量. 作者推舉的辦法
---緣由: 把操作封裝在辦事器，絕對更快一些。
辦法8: 不和辦法
---網上有人寫應用 SQL_CALC_FOUND_ROWS。 沒有事理，勿模擬 。
根本上,可以推行到一切數據庫,事理是一樣的。但辦法5未必能推行到其他數據庫,推行的條件是,其他數據庫支撐ORDER BY操作可以應用索引直接完成排序。
