MySQL分頁技巧、6種分頁辦法總結。本站提示廣大學習愛好者：（MySQL分頁技巧、6種分頁辦法總結）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL分頁技巧、6種分頁辦法總結正文
概述
有同伙問: 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 > (pageNum10) LIMIT M
順應場景: 實用於數據量多的情形(元組數上萬)
緣由: 索引掃描,速度會很快. 有同伙提出: 由於數據查詢出來其實不是依照pk_id排序的，所以會有漏失落數據的情形，只能辦法3
辦法3: 基於索引再排序
語句款式: MySQL中,可用以下辦法: SELECT FROM 表稱號 WHERE id_pk > (pageNum10) 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: 存儲進程類（最好融會上述辦法4)
語句款式: 不再給出
順應場景: 年夜數據量. 作者推舉的辦法
緣由: 把操作封裝在辦事器，絕對更快一些。
辦法6: 不和辦法
網上有人寫應用 SQL_CALC_FOUND_ROWS。 沒有事理，勿模擬
