mysql如何實現(xiàn)高效分頁

先看一下分頁的基本原理（我拿的是CSDN那個百萬級數(shù)據(jù)庫來測試！）：SELECT * FROM `csdn` ORDER BY id DESC LIMIT 100000,2000;

成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設,瑤海企業(yè)網(wǎng)站建設,瑤海品牌網(wǎng)站建設,網(wǎng)站定制,瑤海網(wǎng)站建設報價,網(wǎng)絡營銷,網(wǎng)絡優(yōu)化,瑤海網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

耗時： 0.813ms分析：對上面的mysql語句說明：limit 100000,2000的意思掃描滿足條件的102000行，扔掉前面的100000行，返回最后的2000行。問題就在這里，如果是limit 100000,20000，需要掃描120000行，在一個高并發(fā)的應用里，每次查詢需要掃描超過100000行，性能肯定大打折扣。在《efficient pagination using mysql》中提出的clue方式。利用clue方法，給翻頁提供一些線索，比如還是SELECT * FROM `csdn` order by id desc，按id降序分頁，每頁2000條，當前是第50頁，當前頁條目id最大的是102000，最小的是100000。如果我們只提供上一頁、下一頁這樣的跳轉（不提供到第N頁的跳轉）。那么在處理上一頁的時候SQL語句可以是：

SELECT * FROM `csdn` WHERE id=102000 ORDER BY id DESC LIMIT 2000; #上一頁

耗時：0.015ms處理下一頁的時候SQL語句可以是：

耗時：0.015ms這樣，不管翻多少頁，每次查詢只掃描20行。效率大大提高了！但是，這樣分頁的缺點是只能提供上一頁、下一頁的鏈接形式。

mysql 數(shù)據(jù)量大的表如何做分頁查詢

直接用limit start, count分頁語句， 也是我程序中用的方法：

select * from product limit start, count

當起始頁較小時，查詢沒有性能問題，我們分別看下從10， 100， 1000， 10000開始分頁的執(zhí)行時間（每頁取20條）， 如下：

select * from product limit 10, 20 0.016秒

select * from product limit 100, 20 0.016秒

select * from product limit 1000, 20 0.047秒

select * from product limit 10000, 20 0.094秒

我們已經(jīng)看出隨著起始記錄的增加，時間也隨著增大， 這說明分頁語句limit跟起始頁碼是有很大關系的，那么我們把起始記錄改為40w看下（也就是記錄的一般左右） select * from product limit 400000, 20 3.229秒

再看我們取最后一頁記錄的時間

select * from product limit 866613, 20 37.44秒

難怪搜索引擎抓取我們頁面的時候經(jīng)常會報超時，像這種分頁最大的頁碼頁顯然這種時

間是無法忍受的。

從中我們也能總結出兩件事情：

1）limit語句的查詢時間與起始記錄的位置成正比

2）mysql的limit語句是很方便，但是對記錄很多的表并不適合直接使用。

Mysql使用limit深度分頁優(yōu)化

mysql使用select * limit offset, rows分頁在深度分頁的情況下。性能急劇下降。

limit用于數(shù)據(jù)的分頁查詢，當然也會用于數(shù)據(jù)的截取，下面是limit的用法：

1. 模仿百度、谷歌方案（前端業(yè)務控制）

類似于分段。我們給每次只能翻100頁、超過一百頁的需要重新加載后面的100頁。這樣就解決了每次加載數(shù)量數(shù)據(jù)大 速度慢的問題了

2. 記錄每次取出的最大id， 然后where id 最大id

select * from table_name Where id 最大id limit 10000, 10;

這種方法適用于：除了主鍵ID等離散型字段外，也適用連續(xù)型字段datetime等

最大id由前端分頁pageNum和pageIndex計算出來。

3. IN獲取id

4. join方式 + 覆蓋索引（推薦）

如果對于有where 條件，又想走索引用limit的，必須設計一個索引，將where 放第一位，limit用到的主鍵放第2位，而且只能select 主鍵！

1. jdbcpagingReader使用方式

2. db索引分區(qū)器使用方式

入?yún)?： 表名 如test_table

入?yún)?： 排序索引字段 可以是主鍵，也可以是其他索引。需要保證是唯一索引即可。如：id

入?yún)?： 主鍵可手動傳入，也可以根據(jù)表名計算出來：現(xiàn)在只支持單列主鍵的。 如：id

入?yún)?: 具體表 要分多少塊。如：4

mysql使用limit分頁優(yōu)化方案

準備數(shù)據(jù)是20000000條數(shù)據(jù)

在分頁場景下，使用limit start end，我們分別看下從10000， 100000， 1000000開始分頁的執(zhí)行時間（每頁取10條），如下圖

當start較小時，查詢沒有性能問題，但是如上圖查詢時間所示，隨著start增大，查詢消耗時間也在遞增，在start=10000000時，分頁竟然消耗了2秒多，這是不能忍受的。

由此引出對limit分頁的優(yōu)化,首先來explain該語句，看到查詢沒有使用到任何的索引，進行的是全表掃描，假如limit分頁用到了索引是不是會快很多呢！

explain分析一下,第一行是select * from user_innodb形成的臨時表使用的是全表掃描，第二行是 （SELECT id FROM user_innodb LIMIT 10000000, 10）形成的，使用的是eq_ref，第三行是全表掃描a和bjoin形成的派生表，使用到的是index，所以速度也會快很多

分享文章：mysql分頁性能怎么用 mysql分頁性能問題
URL網(wǎng)址：http://chinadenli.net/article28/dojipcp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、小程序開發(fā)、網(wǎng)站設計公司、服務器托管、定制網(wǎng)站、品牌網(wǎng)站建設

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)