很多應(yīng)用往往只展示最新或最熱門(mén)的幾條記錄，但為了舊記錄仍然可訪問(wèn)，所以就需要個(gè)分頁(yè)的導(dǎo)航欄。然而，如何通過(guò)MySQL更好的實(shí)現(xiàn)分頁(yè)，始終是比較令人頭疼的問(wèn)題。雖然沒(méi)有拿來(lái)就能用的解決辦法，但了解數(shù)據(jù)庫(kù)的底層或多或少有助于優(yōu)化分頁(yè)查詢。
創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括大興網(wǎng)站建設(shè)、大興網(wǎng)站制作、大興網(wǎng)頁(yè)制作以及大興網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，大興網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到大興省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
我們先從一個(gè)常用但性能很差的查詢來(lái)看一看。
SELECT *
FROM city
ORDER BY id DESC
LIMIT 0, 15
這個(gè)查詢耗時(shí)0.00sec。So，這個(gè)查詢有什么問(wèn)題呢？實(shí)際上，這個(gè)查詢語(yǔ)句和參數(shù)都沒(méi)有問(wèn)題，因?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;
真正的問(wèn)題在于offset(分頁(yè)偏移量)很大的時(shí)候，像下面這樣：
SELECT *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;
上面的查詢?cè)谟?M行記錄時(shí)需要0.22sec，通過(guò)EXPLAIN查看SQL的執(zhí)行計(jì)劃可以發(fā)現(xiàn)該SQL檢索了100015行，但最后只需要15行。大的分頁(yè)偏移量會(huì)增加使用的數(shù)據(jù)，MySQL會(huì)將大量最終不會(huì)使用的數(shù)據(jù)加載到內(nèi)存中。就算我們假設(shè)大部分網(wǎng)站的用戶只訪問(wèn)前幾頁(yè)數(shù)據(jù)，但少量的大的分頁(yè)偏移量的請(qǐng)求也會(huì)對(duì)整個(gè)系統(tǒng)造成危害。Facebook意識(shí)到了這一點(diǎn)，但Facebook并沒(méi)有為了每秒可以處理更多的請(qǐng)求而去優(yōu)化數(shù)據(jù)庫(kù)，而是將重心放在將請(qǐng)求響應(yīng)時(shí)間的方差變小。
對(duì)于分頁(yè)請(qǐng)求，還有一個(gè)信息也很重要，就是總共的記錄數(shù)。我們可以通過(guò)下面的查詢很容易的獲取總的記錄數(shù)。
SELECT COUNT(*)
FROM city;
然而，上面的SQL在采用InnoDB為存儲(chǔ)引擎時(shí)需要耗費(fèi)9.28sec。一個(gè)不正確的優(yōu)化是采用 SQL_CALC_FOUND_ROWS,SQL_CALC_FOUND_ROWS 可以在能夠在分頁(yè)查詢時(shí)事先準(zhǔn)備好符合條件的記錄數(shù)，隨后只要執(zhí)行一句 select FOUND_ROWS(); 就能獲得總記錄數(shù)。但是在大多數(shù)情況下，查詢語(yǔ)句簡(jiǎn)短并不意味著性能的提高。不幸的是，這種分頁(yè)查詢方式在許多主流框架中都有用到，下面看看這個(gè)語(yǔ)句的查詢性能。
SELECT SQL_CALC_FOUND_ROWS *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;
這個(gè)語(yǔ)句耗時(shí)20.02sec，是上一個(gè)的兩倍。事實(shí)證明使用 SQL_CALC_FOUND_ROWS 做分頁(yè)是很糟糕的想法。
下面來(lái)看看到底如何優(yōu)化。文章分為兩部分，第一部分是如何獲取記錄的總數(shù)目，第二部分是獲取真正的記錄。
高效的計(jì)算行數(shù)
如果采用的引擎是MyISAM，可以直接執(zhí)行COUNT(*)去獲取行數(shù)即可。相似的，在堆表中也會(huì)將行數(shù)存儲(chǔ)到表的元信息中。但如果引擎是InnoDB情況就會(huì)復(fù)雜一些，因?yàn)镮nnoDB不保存表的具體行數(shù)。
我們可以將行數(shù)緩存起來(lái)，然后可以通過(guò)一個(gè)守護(hù)進(jìn)程定期更新或者用戶的某些操作導(dǎo)致緩存失效時(shí)，執(zhí)行下面的語(yǔ)句：
SELECT COUNT(*)
FROM city
USE INDEX(PRIMARY);
獲取記錄
下面進(jìn)入這篇文章最重要的部分，獲取分頁(yè)要展示的記錄。上面已經(jīng)說(shuō)過(guò)了，大的偏移量會(huì)影響性能，所以我們要重寫(xiě)查詢語(yǔ)句。為了演示，我們創(chuàng)建一個(gè)新的表“news”，按照時(shí)事性排序(最新發(fā)布的在最前面)，實(shí)現(xiàn)一個(gè)高性能的分頁(yè)。為了簡(jiǎn)單，我們就假設(shè)最新發(fā)布的新聞的Id也是最大的。
CREATE TABLE news(
id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(128) NOT NULL
) ENGINE=InnoDB;
一個(gè)比較高效的方式是基于用戶展示的最后一個(gè)新聞Id。查詢下一頁(yè)的語(yǔ)句如下，需要傳入當(dāng)前頁(yè)面展示的最后一個(gè)Id。
SELECT *
FROM news WHERE id $last_id
ORDER BY id DESC
LIMIT $perpage
查詢上一頁(yè)的語(yǔ)句類似，只不過(guò)需要傳入當(dāng)前頁(yè)的第一個(gè)Id，并且要逆序。
SELECT *
FROM news WHERE id $last_id
ORDER BY id ASC
LIMIT $perpage
上面的查詢方式適合實(shí)現(xiàn)簡(jiǎn)易的分頁(yè)，即不顯示具體的頁(yè)數(shù)導(dǎo)航，只顯示“上一頁(yè)”和“下一頁(yè)”，例如博客中頁(yè)腳顯示“上一頁(yè)”，“下一頁(yè)”的按鈕。但如果要實(shí)現(xiàn)真正的頁(yè)面導(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;
通過(guò)上面的語(yǔ)句可以為每一個(gè)分頁(yè)的按鈕計(jì)算出一個(gè)offset對(duì)應(yīng)的id。這種方法還有一個(gè)好處。假設(shè)，網(wǎng)站上正在發(fā)布一片新的文章，那么所有文章的位置都會(huì)往后移一位，所以如果用戶在發(fā)布文章時(shí)換頁(yè)，那么他會(huì)看見(jiàn)一篇文章兩次。如果固定了每個(gè)按鈕的offset Id，這個(gè)問(wèn)題就迎刃而解了。Mark Callaghan發(fā)表過(guò)一篇類似的博客，利用了組合索引和兩個(gè)位置變量，但是基本思想是一致的。
如果表中的記錄很少被刪除、修改，還可以將記錄對(duì)應(yīng)的頁(yè)碼存儲(chǔ)到表中，并在該列上創(chuàng)建合適的索引。采用這種方式，當(dāng)新增一個(gè)記錄的時(shí)候，需要執(zhí)行下面的查詢重新生成對(duì)應(yīng)的頁(yè)號(hào)。
SET p:= 0;
UPDATE news SET page=CEIL((p:= p + 1) / $perpage) ORDER BY id DESC;
當(dāng)然，也可以新增一個(gè)專用于分頁(yè)的表，可以用個(gè)后臺(tái)程序來(lá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)在想獲取任意一頁(yè)的元素就很簡(jiǎn)單了：
SELECT *
FROM news A
JOIN pagination B ON A.id=B.ID
WHERE page=$offset;
還有另外一種與上種方法比較相似的方法來(lái)做分頁(yè)，這種方式比較試用于數(shù)據(jù)集相對(duì)小，并且沒(méi)有可用的索引的情況下—比如處理搜索結(jié)果時(shí)。在一個(gè)普通的服務(wù)器上執(zhí)行下面的查詢，當(dāng)有2M條記錄時(shí)，要耗費(fèi)2sec左右。這種方式比較簡(jiǎn)單，創(chuàng)建一個(gè)用來(lái)存儲(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;
接下來(lái)就可以向下面一樣執(zhí)行分頁(yè)查詢了。
SELECT *
FROM _tmp
WHERE OFFSET = $offset
ORDER BY OFFSET
LIMIT $perpage;
簡(jiǎn)單來(lái)說(shuō)，對(duì)于分頁(yè)的優(yōu)化就是。。。避免數(shù)據(jù)量大時(shí)掃描過(guò)多的記錄。
offset+limit方式的分頁(yè)查詢，當(dāng)數(shù)據(jù)表超過(guò)100w條記錄，性能會(huì)很差。
主要原因是offset limit的分頁(yè)方式是從頭開(kāi)始查詢，然后舍棄前offset個(gè)記錄，所以offset偏移量越大，查詢速度越慢。
比如: 讀第10000到10019行元素(pk是主鍵/唯一鍵).
使用order by id可以在查詢時(shí)使用主鍵索引。
但是這種方式在id為uuid的時(shí)候就會(huì)出現(xiàn)問(wèn)題?？梢允褂脀here in的方式解決：
帶條件的查詢：
如果在分頁(yè)查詢中添加了where條件例如 type = 'a’這樣的條件，sql變成 ：
這種情況因?yàn)閠ype沒(méi)有使用索引也會(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ì)帶來(lái)性能上的問(wèn)題，在查詢時(shí)也會(huì)遇到問(wèn)題。
因?yàn)樵谑褂胹elect id from table limit 10000,10 查詢id數(shù)據(jù)時(shí)，默認(rèn)是對(duì)id進(jìn)行排序，返回的是排序后的id結(jié)果，如果我們想按插入順序查詢結(jié)果，這樣查詢出來(lái)的結(jié)果就與我們的需求不相符。
聚集索引跟非聚集索引：聚集索引類似與新華字典的拼音，根據(jù)拼音搜索到的信息都是連續(xù)的，可以很快獲取到它前后的信息。非聚集索引類似于部首查詢，信息存放的位置可能不在一個(gè)區(qū)域。對(duì)經(jīng)常使用范圍查詢的字段考慮使用聚集索引。
InnoDB中索引分為聚簇索引（主鍵索引）和非聚簇索引（非主鍵索引），聚簇索引的葉子節(jié)點(diǎn)中保存的是整行記錄，而非聚簇索引的葉子節(jié)點(diǎn)中保存的是該行記錄的主鍵的值。
如果您的表上定義有主鍵，該主鍵索引是聚集索引。
如果你不定義為您的表的主鍵時(shí)，MySQL取第一個(gè)唯一索引（unique）而且只含非空列（NOT NULL）作為主鍵，InnoDB使用它作為聚集索引。
如果沒(méi)有這樣的列，InnoDB就自己產(chǎn)生一個(gè)這樣的ID值，
優(yōu)先選index key_len小的索引進(jìn)行count(*),盡量不使用聚簇索引
在沒(méi)有where條件的情況下，count(*)和count(常量)，如果有非聚簇索引，mysql會(huì)自動(dòng)選擇非聚簇索引，因?yàn)榉蔷鄞厮饕嫉目臻g小，如果沒(méi)有非聚簇索引會(huì)使用聚集索引。count(primary key)主鍵id為聚集索引，使用聚集索引。有where條件的情況下，是否使用索引會(huì)根據(jù)where條件判斷。
當(dāng)業(yè)務(wù)上按照月份分表，但是前端h5需要分頁(yè)展示，小伙伴們不知有沒(méi)有遇到這個(gè)這個(gè)需求最后怎么完成的。
我這里想了一個(gè)解決思路，可能還不完善，希望能拋轉(zhuǎn)引玉。
1、入?yún)ageNo 為頁(yè)號(hào)碼，如果為1那么就是第一頁(yè)。pageSize 可以是入?yún)⒁部啥ㄋ?，這里定死10條。Limit 是數(shù)據(jù)偏移標(biāo)記，根據(jù)入?yún)ageNo 計(jì)算出來(lái)的，Limit=(pageNo-1)*pageSize。假設(shè)A表有41條數(shù)據(jù)符合，B表有51條數(shù)據(jù)符合，如下圖。
有幾種種情況? ?1.如果limitA表41條 那么需要從A表中取數(shù)據(jù)，（1）如果Limit+pageSizeCount直接獲取數(shù)據(jù)即可（2）如果Limit+pageSizeCount,那么需要從A 表取部分?jǐn)?shù)據(jù)從B表取一部分?jǐn)?shù)據(jù)。
1.如果limitA表41條? 那么需要從B表取數(shù)據(jù)，如果B數(shù)據(jù)依然不足，那么重復(fù)以上的步驟。如下圖
重慶分公司
重慶分公司
