MySQL分頁查詢LIMIT

SELECT * FROM table LIMIT [offset,] rows;

你所需要的網站建設服務，我們均能行業靠前的水平為你提供.標準是產品質量的保證，主要從事網站建設、成都網站設計、企業網站建設、手機網站制作設計、網頁設計、品牌網站設計、網頁制作、做網站、建網站。創新互聯公司擁有實力堅強的技術研發團隊及素養的視覺設計專才。

offset ：偏移，從 offset 條之后開始選擇數據，如果 offset 不填，則 offset 為0。

rows ：從偏移后開始，選擇 rows 條數據。

特點：左開右閉，即選取 (offset,offset+rows] 的數據。

SELECT * FROM table LIMIT 5;

SELECT * FROM table LIMIT 0,5;

區間：(0,5]

offset=0

rows=5-0=5

SELECT * FROM table LIMIT 2,4;

區間：(1,5]

offset=1

rows=5-1=4

SELECT * FROM table LIMIT n,m;

區間：(n-1,m]

offset=n-1

rows=m-n+1

mysql如何做分頁查詢？

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

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

SELECT *

FROM city

ORDER BY id DESC

LIMIT 0, 15

這個查詢耗時0.00sec。So，這個查詢有什么問題呢？實際上，這個查詢語句和參數都沒有問題，因為它用到了下面表的主鍵，而且只讀取15條記錄。

CREATE TABLE city (

id int(10) unsigned NOT NULL AUTO_INCREMENT,

city varchar(128) NOT NULL,

PRIMARY KEY (id)

) ENGINE=InnoDB;

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

SELECT *

FROM city

ORDER BY id DESC

LIMIT 100000, 15;

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

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

SELECT COUNT(*)

FROM city;

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

SELECT SQL_CALC_FOUND_ROWS *

FROM city

ORDER BY id DESC

LIMIT 100000, 15;

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

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

高效的計算行數

如果采用的引擎是MyISAM，可以直接執行COUNT(*)去獲取行數即可。相似的，在堆表中也會將行數存儲到表的元信息中。但如果引擎是InnoDB情況就會復雜一些，因為InnoDB不保存表的具體行數。

我們可以將行數緩存起來，然后可以通過一個守護進程定期更新或者用戶的某些操作導致緩存失效時，執行下面的語句：

SELECT COUNT(*)

FROM city

USE INDEX(PRIMARY);

獲取記錄

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

CREATE TABLE news(

id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,

title VARCHAR(128) NOT NULL

) ENGINE=InnoDB;

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

SELECT *

FROM news WHERE id $last_id

ORDER BY id DESC

LIMIT $perpage

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

SELECT *

FROM news WHERE id $last_id

ORDER BY id ASC

LIMIT $perpage

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

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;

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

如果表中的記錄很少被刪除、修改，還可以將記錄對應的頁碼存儲到表中，并在該列上創建合適的索引。采用這種方式，當新增一個記錄的時候，需要執行下面的查詢重新生成對應的頁號。

SET p:= 0;

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

當然，也可以新增一個專用于分頁的表，可以用個后臺程序來維護。

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;

現在想獲取任意一頁的元素就很簡單了：

SELECT *

FROM news A

JOIN pagination B ON A.id=B.ID

WHERE page=$offset;

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

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;

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

SELECT *

FROM _tmp

WHERE OFFSET = $offset

ORDER BY OFFSET

LIMIT $perpage;

簡單來說，對于分頁的優化就是。。。避免數據量大時掃描過多的記錄。

mysql 分表分頁查詢解決思路

當業務上按照月份分表，但是前端h5需要分頁展示，小伙伴們不知有沒有遇到這個這個需求最后怎么完成的。

我這里想了一個解決思路，可能還不完善，希望能拋轉引玉。

1、入參pageNo 為頁號碼，如果為1那么就是第一頁。pageSize 可以是入參也可定死，這里定死10條。Limit 是數據偏移標記，根據入參pageNo 計算出來的，Limit=(pageNo-1)*pageSize。假設A表有41條數據符合，B表有51條數據符合，如下圖。

有幾種種情況? ?1.如果limitA表41條 那么需要從A表中取數據，（1）如果Limit+pageSizeCount直接獲取數據即可（2）如果Limit+pageSizeCount,那么需要從A 表取部分數據從B表取一部分數據。

1.如果limitA表41條? 那么需要從B表取數據，如果B數據依然不足，那么重復以上的步驟。如下圖

MySQL大數據量分頁查詢方法及其優化

使用子查詢優化大數據量分頁查詢

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

使用id限定優化大數據量分頁查詢

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

當然了，也可以使用in的方式來進行查詢，這種方式經常用在多表關聯的情況下，使用其他表查詢的id集合來進行查詢：

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

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

MySQL百萬級數據量分頁查詢方法及其優化建議

offset+limit方式的分頁查詢，當數據表超過100w條記錄，性能會很差。

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

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

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

但是這種方式在id為uuid的時候就會出現問題。可以使用where in的方式解決：

帶條件的查詢：

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

這種情況因為type沒有使用索引也會導致查詢速度變慢。但是只添加type為索引查詢速度還是很慢,是因為查詢的數據量太多了。這個時候考慮添加組合索引，組合索引的順序要where條件字段在前，id在后，如 (type,id)，因為組合索引查詢時用到了type索引，而type跟id是組合索引的關系，如果只select id ，那么直接就可以按組合索引返回id，而不需要再進行一次查詢去返回id

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

因為在使用select id from table limit 10000,10 查詢id數據時，默認是對id進行排序，返回的是排序后的id結果，如果我們想按插入順序查詢結果，這樣查詢出來的結果就與我們的需求不相符。

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

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

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

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

如果沒有這樣的列，InnoDB就自己產生一個這樣的ID值，

優先選index key_len小的索引進行count(*),盡量不使用聚簇索引

在沒有where條件的情況下，count(*)和count(常量)，如果有非聚簇索引，mysql會自動選擇非聚簇索引，因為非聚簇索引所占的空間小，如果沒有非聚簇索引會使用聚集索引。count(primary key)主鍵id為聚集索引，使用聚集索引。有where條件的情況下，是否使用索引會根據where條件判斷。

Mysql分頁查詢

limit "(currentPage -1 ) * pageSize",pageSize;--limit x,y;//x表示從數據庫查詢的臨時表的第x行開始，pageSize表示獲得幾行，即每頁的數據條數；x=(currentPage -1 ) * pageSize;y=pageSize;

pageSize就是lineSize,就是分頁后每頁顯示多少行記錄。