mysql的分頁怎么用 mysql分頁怎么寫

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

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

在榆陽等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供做網(wǎng)站、成都網(wǎng)站制作 網(wǎng)站設(shè)計(jì)制作定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計(jì),成都全網(wǎng)營銷推廣,成都外貿(mào)網(wǎng)站制作,榆陽網(wǎng)站建設(shè)費(fèi)用合理。

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

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

類似于分段。我們給每次只能翻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計(jì)算出來。

3. IN獲取id

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

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

1. jdbcpagingReader使用方式

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

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

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

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

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

MySQL大數(shù)據(jù)量分頁查詢方法及其優(yōu)化

使用子查詢優(yōu)化大數(shù)據(jù)量分頁查詢

這種方式的做法是先定位偏移位置的id，然后再往后查詢，適用于id遞增的情況。

使用id限定優(yōu)化大數(shù)據(jù)量分頁查詢

使用這種方式需要先假設(shè)數(shù)據(jù)表的id是連續(xù)遞增的，我們根據(jù)查詢的頁數(shù)和查詢的記錄數(shù)可以算出查詢的id的范圍，可以使用 id between and 來查詢：

當(dāng)然了，也可以使用in的方式來進(jìn)行查詢，這種方式經(jīng)常用在多表關(guān)聯(lián)的情況下，使用其他表查詢的id集合來進(jìn)行查詢：

但是使用這種in查詢方式的時(shí)候要注意的是，某些MySQL版本并不支持在in子句中使用limit子句。

參考 sql優(yōu)化之大數(shù)據(jù)量分頁查詢（mysql） - yanggb - 博客園 (cnblogs.com)

MySQL分頁的sql語言怎么寫？

1、首先我們建立一個(gè)表表的數(shù)據(jù)，這個(gè)表里有25條數(shù)據(jù)，id從1到25。（下圖是部分截圖）

2、要分頁數(shù)據(jù)，首先我們假設(shè)一頁有10條數(shù)據(jù)，我們可以用mysql的limit關(guān)鍵字來限定返回多少條數(shù)據(jù)。并且用orderby來排序數(shù)據(jù)，這里用id來排序。所以第一頁的sql可以如圖這樣寫。

3、執(zhí)行后得到的數(shù)據(jù)如圖，就是id從1到10的前10條數(shù)據(jù)，因?yàn)槲覀兪前磇d升序來排序的。

4、上面第一頁的sql是簡化的寫法，完整的寫法如圖，得到的結(jié)果和上圖的一模一樣。代碼里limit0,10的意思是從第一條數(shù)據(jù)開始，取10條數(shù)據(jù)。（注意的是第一條數(shù)據(jù)是從0開始的）

5、那么第二頁的數(shù)據(jù)，關(guān)鍵是要知道是從哪一條數(shù)據(jù)開始，可以用這個(gè)公式得到：(頁碼-1)?*每頁顯示多少條，即（2-1)*10=10,所以sql語句如圖,limit10,10。

6、執(zhí)行后，結(jié)果正確，得到id從11到20的10條數(shù)據(jù)。

7、同理第三頁數(shù)據(jù)的sql如圖，br/就是limit20,10。

8、查詢的結(jié)果如圖，因?yàn)檫@頁只剩下5條數(shù)據(jù)了，所以只顯示5條數(shù)據(jù)。如果你有更多頁的數(shù)據(jù)，后面的數(shù)據(jù)只需要按上面的公式，得到從哪行開始，就可以寫對(duì)應(yīng)的sql語句了。

mysql如何做分頁查詢？

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

select * from product limit start, count

當(dāng)起始頁較小時(shí)，查詢沒有性能問題，我們分別看下從10， 100， 1000， 10000開始分頁的執(zhí)行時(shí)間（每頁取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)看出隨著起始記錄的增加，時(shí)間也隨著增大， 這說明分頁語句limit跟起始頁碼是有很大關(guān)系的，那么我們把起始記錄改為40w看下（也就是記錄的一般左右） select * from product limit 400000, 20 3.229秒

再看我們?nèi)∽詈笠豁撚涗浀臅r(shí)間

select * from product limit 866613, 20 37.44秒

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

間是無法忍受的。

從中我們也能總結(jié)出兩件事情：

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

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

mysql數(shù)據(jù)庫分頁

很多應(yīng)用往往只展示最新或最熱門的幾條記錄，但為了舊記錄仍然可訪問，所以就需要個(gè)分頁的導(dǎo)航欄。然而，如何通過MySQL更好的實(shí)現(xiàn)分頁，始終是比較令人頭疼的問題。雖然沒有拿來就能用的解決辦法，但了解數(shù)據(jù)庫的底層或多或少有助于優(yōu)化分頁查詢。

我們先從一個(gè)常用但性能很差的查詢來看一看。

SELECT *

FROM city

ORDER BY id DESC

LIMIT 0, 15

這個(gè)查詢耗時(shí)0.00sec。So，這個(gè)查詢有什么問題呢？實(shí)際上，這個(gè)查詢語句和參數(shù)都沒有問題，因?yàn)樗玫搅讼旅姹淼闹麈I，而且只讀取15條記錄。

CREATE TABLE city (

id int(10) unsigned NOT NULL AUTO_INCREMENT,

city varchar(128) NOT NULL,

PRIMARY KEY (id)

) ENGINE=InnoDB;

真正的問題在于offset(分頁偏移量)很大的時(shí)候，像下面這樣：

SELECT *

FROM city

ORDER BY id DESC

LIMIT 100000, 15;

上面的查詢在有2M行記錄時(shí)需要0.22sec，通過EXPLAIN查看SQL的執(zhí)行計(jì)劃可以發(fā)現(xiàn)該SQL檢索了100015行，但最后只需要15行。大的分頁偏移量會(huì)增加使用的數(shù)據(jù)，MySQL會(huì)將大量最終不會(huì)使用的數(shù)據(jù)加載到內(nèi)存中。就算我們假設(shè)大部分網(wǎng)站的用戶只訪問前幾頁數(shù)據(jù)，但少量的大的分頁偏移量的請求也會(huì)對(duì)整個(gè)系統(tǒng)造成危害。Facebook意識(shí)到了這一點(diǎn)，但Facebook并沒有為了每秒可以處理更多的請求而去優(yōu)化數(shù)據(jù)庫，而是將重心放在將請求響應(yīng)時(shí)間的方差變小。

對(duì)于分頁請求，還有一個(gè)信息也很重要，就是總共的記錄數(shù)。我們可以通過下面的查詢很容易的獲取總的記錄數(shù)。

SELECT COUNT(*)

FROM city;

然而，上面的SQL在采用InnoDB為存儲(chǔ)引擎時(shí)需要耗費(fèi)9.28sec。一個(gè)不正確的優(yōu)化是采用 SQL_CALC_FOUND_ROWS,SQL_CALC_FOUND_ROWS 可以在能夠在分頁查詢時(shí)事先準(zhǔn)備好符合條件的記錄數(shù)，隨后只要執(zhí)行一句 select FOUND_ROWS(); 就能獲得總記錄數(shù)。但是在大多數(shù)情況下，查詢語句簡短并不意味著性能的提高。不幸的是，這種分頁查詢方式在許多主流框架中都有用到，下面看看這個(gè)語句的查詢性能。

SELECT SQL_CALC_FOUND_ROWS *

FROM city

ORDER BY id DESC

LIMIT 100000, 15;

這個(gè)語句耗時(shí)20.02sec，是上一個(gè)的兩倍。事實(shí)證明使用 SQL_CALC_FOUND_ROWS 做分頁是很糟糕的想法。

下面來看看到底如何優(yōu)化。文章分為兩部分，第一部分是如何獲取記錄的總數(shù)目，第二部分是獲取真正的記錄。

高效的計(jì)算行數(shù)

如果采用的引擎是MyISAM，可以直接執(zhí)行COUNT(*)去獲取行數(shù)即可。相似的，在堆表中也會(huì)將行數(shù)存儲(chǔ)到表的元信息中。但如果引擎是InnoDB情況就會(huì)復(fù)雜一些，因?yàn)镮nnoDB不保存表的具體行數(shù)。

我們可以將行數(shù)緩存起來，然后可以通過一個(gè)守護(hù)進(jìn)程定期更新或者用戶的某些操作導(dǎo)致緩存失效時(shí)，執(zhí)行下面的語句：

SELECT COUNT(*)

FROM city

USE INDEX(PRIMARY);

獲取記錄

下面進(jìn)入這篇文章最重要的部分，獲取分頁要展示的記錄。上面已經(jīng)說過了，大的偏移量會(huì)影響性能，所以我們要重寫查詢語句。為了演示，我們創(chuàng)建一個(gè)新的表“news”，按照時(shí)事性排序(最新發(fā)布的在最前面)，實(shí)現(xiàn)一個(gè)高性能的分頁。為了簡單，我們就假設(shè)最新發(fā)布的新聞的Id也是最大的。

CREATE TABLE news(

id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,

title VARCHAR(128) NOT NULL

) ENGINE=InnoDB;

一個(gè)比較高效的方式是基于用戶展示的最后一個(gè)新聞Id。查詢下一頁的語句如下，需要傳入當(dāng)前頁面展示的最后一個(gè)Id。

SELECT *

FROM news WHERE id $last_id

ORDER BY id DESC

LIMIT $perpage

查詢上一頁的語句類似，只不過需要傳入當(dāng)前頁的第一個(gè)Id，并且要逆序。

SELECT *

FROM news WHERE id $last_id

ORDER BY id ASC

LIMIT $perpage

上面的查詢方式適合實(shí)現(xiàn)簡易的分頁，即不顯示具體的頁數(shù)導(dǎo)航，只顯示“上一頁”和“下一頁”，例如博客中頁腳顯示“上一頁”，“下一頁”的按鈕。但如果要實(shí)現(xiàn)真正的頁面導(dǎo)航還是很難的,下面看看另一種方式。

SELECT id

FROM (

SELECT id, ((@cnt:= @cnt + 1) + $perpage - 1) % $perpage cnt

FROM news

JOIN (SELECT @cnt:= 0)T

WHERE id $last_id

ORDER BY id DESC

LIMIT $perpage * $buttons

)C

WHERE cnt = 0;

通過上面的語句可以為每一個(gè)分頁的按鈕計(jì)算出一個(gè)offset對(duì)應(yīng)的id。這種方法還有一個(gè)好處。假設(shè)，網(wǎng)站上正在發(fā)布一片新的文章，那么所有文章的位置都會(huì)往后移一位，所以如果用戶在發(fā)布文章時(shí)換頁，那么他會(huì)看見一篇文章兩次。如果固定了每個(gè)按鈕的offset Id，這個(gè)問題就迎刃而解了。Mark Callaghan發(fā)表過一篇類似的博客，利用了組合索引和兩個(gè)位置變量，但是基本思想是一致的。

如果表中的記錄很少被刪除、修改，還可以將記錄對(duì)應(yīng)的頁碼存儲(chǔ)到表中，并在該列上創(chuàng)建合適的索引。采用這種方式，當(dāng)新增一個(gè)記錄的時(shí)候，需要執(zhí)行下面的查詢重新生成對(duì)應(yīng)的頁號(hào)。

SET p:= 0;

UPDATE news SET page=CEIL((p:= p + 1) / $perpage) ORDER BY id DESC;

當(dāng)然，也可以新增一個(gè)專用于分頁的表，可以用個(gè)后臺(tái)程序來維護(hù)。

UPDATE pagination T

JOIN (

SELECT id, CEIL((p:= p + 1) / $perpage) page

FROM news

ORDER BY id

)C

ON C.id = T.id

SET T.page = C.page;

現(xiàn)在想獲取任意一頁的元素就很簡單了：

SELECT *

FROM news A

JOIN pagination B ON A.id=B.ID

WHERE page=$offset;

還有另外一種與上種方法比較相似的方法來做分頁，這種方式比較試用于數(shù)據(jù)集相對(duì)小，并且沒有可用的索引的情況下—比如處理搜索結(jié)果時(shí)。在一個(gè)普通的服務(wù)器上執(zhí)行下面的查詢，當(dāng)有2M條記錄時(shí)，要耗費(fèi)2sec左右。這種方式比較簡單，創(chuàng)建一個(gè)用來存儲(chǔ)所有Id的臨時(shí)表即可(這也是最耗費(fèi)性能的地方)。

CREATE TEMPORARY TABLE _tmp (KEY SORT(random))

SELECT id, FLOOR(RAND() * 0x8000000) random

FROM city;

ALTER TABLE _tmp ADD OFFSET INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, DROP INDEX SORT,ORDER BY random;

接下來就可以向下面一樣執(zhí)行分頁查詢了。

SELECT *

FROM _tmp

WHERE OFFSET = $offset

ORDER BY OFFSET

LIMIT $perpage;

簡單來說，對(duì)于分頁的優(yōu)化就是。。。避免數(shù)據(jù)量大時(shí)掃描過多的記錄。

MySQL百萬級(jí)數(shù)據(jù)量分頁查詢方法及其優(yōu)化建議

offset+limit方式的分頁查詢，當(dāng)數(shù)據(jù)表超過100w條記錄，性能會(huì)很差。

主要原因是offset limit的分頁方式是從頭開始查詢，然后舍棄前offset個(gè)記錄，所以offset偏移量越大，查詢速度越慢。

比如: 讀第10000到10019行元素(pk是主鍵/唯一鍵).

使用order by id可以在查詢時(shí)使用主鍵索引。

但是這種方式在id為uuid的時(shí)候就會(huì)出現(xiàn)問題?？梢允褂脀here in的方式解決：

帶條件的查詢：

如果在分頁查詢中添加了where條件例如 type = 'a’這樣的條件，sql變成 ：

這種情況因?yàn)閠ype沒有使用索引也會(huì)導(dǎo)致查詢速度變慢。但是只添加type為索引查詢速度還是很慢,是因?yàn)椴樵兊臄?shù)據(jù)量太多了。這個(gè)時(shí)候考慮添加組合索引，組合索引的順序要where條件字段在前，id在后，如 (type,id)，因?yàn)榻M合索引查詢時(shí)用到了type索引，而type跟id是組合索引的關(guān)系，如果只select id ，那么直接就可以按組合索引返回id，而不需要再進(jìn)行一次查詢?nèi)シ祷豬d

使用uuid作為主鍵不僅會(huì)帶來性能上的問題，在查詢時(shí)也會(huì)遇到問題。

因?yàn)樵谑褂胹elect id from table limit 10000,10 查詢id數(shù)據(jù)時(shí)，默認(rèn)是對(duì)id進(jìn)行排序，返回的是排序后的id結(jié)果，如果我們想按插入順序查詢結(jié)果，這樣查詢出來的結(jié)果就與我們的需求不相符。

聚集索引跟非聚集索引：聚集索引類似與新華字典的拼音，根據(jù)拼音搜索到的信息都是連續(xù)的，可以很快獲取到它前后的信息。非聚集索引類似于部首查詢，信息存放的位置可能不在一個(gè)區(qū)域。對(duì)經(jīng)常使用范圍查詢的字段考慮使用聚集索引。

InnoDB中索引分為聚簇索引（主鍵索引）和非聚簇索引（非主鍵索引），聚簇索引的葉子節(jié)點(diǎn)中保存的是整行記錄，而非聚簇索引的葉子節(jié)點(diǎn)中保存的是該行記錄的主鍵的值。

如果您的表上定義有主鍵，該主鍵索引是聚集索引。

如果你不定義為您的表的主鍵時(shí)，MySQL取第一個(gè)唯一索引（unique）而且只含非空列（NOT NULL）作為主鍵，InnoDB使用它作為聚集索引。

如果沒有這樣的列，InnoDB就自己產(chǎn)生一個(gè)這樣的ID值，

優(yōu)先選index key_len小的索引進(jìn)行count(*),盡量不使用聚簇索引

在沒有where條件的情況下，count(*)和count(常量)，如果有非聚簇索引，mysql會(huì)自動(dòng)選擇非聚簇索引，因?yàn)榉蔷鄞厮饕嫉目臻g小，如果沒有非聚簇索引會(huì)使用聚集索引。count(primary key)主鍵id為聚集索引，使用聚集索引。有where條件的情況下，是否使用索引會(huì)根據(jù)where條件判斷。

網(wǎng)站名稱：mysql的分頁怎么用 mysql分頁怎么寫
分享地址：http://muchs.cn/article32/hjdhpc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、網(wǎng)站制作、關(guān)鍵詞優(yōu)化、定制網(wǎng)站、自適應(yīng)網(wǎng)站、網(wǎng)站維護(hù)

廣告

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