背景

基本上只要是做后臺(tái)開發(fā)，都會(huì)接觸到分頁(yè)這個(gè)需求或者功能吧?；旧洗蠹叶际菚?huì)用MySQL的LIMIT來(lái)處理，而且我現(xiàn)在負(fù)責(zé)的項(xiàng)目也是這樣寫的。但是一旦數(shù)據(jù)量起來(lái)了，其實(shí)LIMIT的效率會(huì)極其的低，這一篇文章就來(lái)講一下LIMIT子句優(yōu)化的。

LIMIT優(yōu)化

很多業(yè)務(wù)場(chǎng)景都需要用到分頁(yè)這個(gè)功能，基本上都是用LIMIT來(lái)實(shí)現(xiàn)。

建表并且插入200萬(wàn)條數(shù)據(jù)：

# 新建一張t5表
CREATE TABLE `t5` (
 `id` int NOT NULL AUTO_INCREMENT,
 `name` varchar(50) NOT NULL,
 `text` varchar(100) NOT NULL,
 PRIMARY KEY (`id`),
 KEY `ix_name` (`name`),
 KEY `ix_test` (`text`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

# 創(chuàng)建存儲(chǔ)過(guò)程插入200萬(wàn)數(shù)據(jù)
CREATE PROCEDURE t5_insert_200w()
BEGIN
 DECLARE i INT;
 SET i=1000000;
 WHILE i=3000000 DO
 INSERT INTO t5(`name`,text) VALUES('god-jiang666',concat('text', i));
 SET i=i+1;
 END WHILE;
END;

# 調(diào)用存儲(chǔ)過(guò)程插入200萬(wàn)數(shù)據(jù)
call t5_insert_200w();

在翻頁(yè)比較少的情況下，LIMIT是不會(huì)出現(xiàn)任何性能上的問題的。

但是如果用戶需要查到最后面的頁(yè)數(shù)呢？

通常情況下，我們要保證所有的頁(yè)面可以正常跳轉(zhuǎn)，因?yàn)椴粫?huì)使用order by xxx desc這樣的倒序SQL來(lái)查詢后面的頁(yè)數(shù)，而是采用正序順序來(lái)做分頁(yè)查詢：

select * from t5 order by text limit 100000, 10;

采用這種SQL查詢分頁(yè)的話，從200萬(wàn)數(shù)據(jù)中取出這10行數(shù)據(jù)的代價(jià)是非常大的，需要先排序查出前1000010條記錄，然后拋棄前面1000000條。我的macbook pro跑出來(lái)花了5.578秒。

接下來(lái)我們來(lái)看一下，上面這條SQL語(yǔ)句的執(zhí)行計(jì)劃：

explain select * from t5 order by text limit 1000000, 10;

從執(zhí)行計(jì)劃可以看出，在大分頁(yè)的情況下，MySQL沒有走索引掃描，即使text字段我已經(jīng)加上了索引。

這是為什么呢？

回到MySQL索引（二）如何設(shè)計(jì)索引中有提及到，MySQL數(shù)據(jù)庫(kù)的查詢優(yōu)化器是采用了基于代價(jià)的，而查詢代價(jià)的估算是基于CPU代價(jià)和IO代價(jià)。

如果MySQL在查詢代價(jià)估算中，認(rèn)為全表掃描方式比走索引掃描的方式效率更高的話，就會(huì)放棄索引，直接全表掃描。

這就是為什么在大分頁(yè)的SQL查詢中，明明給該字段加了索引，但是MySQL卻走了全表掃描的原因。

然后我們繼續(xù)用上面的查詢SQL來(lái)驗(yàn)證我的猜想：

explain select * from t5 order by text limit 7774, 10;

explain select * from t5 order by text limit 7775, 10;

以上的實(shí)驗(yàn)均在我的mbp上運(yùn)行的，在7774這個(gè)臨界點(diǎn)上，MySQL分別采用了索引掃描和全表掃描的查詢優(yōu)化方式。

所以可以認(rèn)為MySQL會(huì)根據(jù)它自己的代價(jià)查詢優(yōu)化器來(lái)判斷是否使用索引。

由于MySQL的查詢優(yōu)化器的算法核心是我們無(wú)法人工干預(yù)的，所以我們的優(yōu)化思路就要著手于如何讓分頁(yè)維持在最佳的的分頁(yè)臨界點(diǎn)。

優(yōu)化方式

1、使用覆蓋索引

如果一條SQL語(yǔ)句，通過(guò)索引可以直接獲取查詢的結(jié)果，不再需要回表查詢，就稱這個(gè)索引為覆蓋索引。

在MySQL數(shù)據(jù)庫(kù)中使用explain關(guān)鍵字查看執(zhí)行計(jì)劃，如果extra這一列顯示Using index，就表示這條SQL語(yǔ)句使用了覆蓋索引。

讓我們來(lái)對(duì)比一下使用了覆蓋索引，性能會(huì)提升多少吧。

# 沒有使用覆蓋索引
select * from t5 order by text limit 1000000, 10;

這次查詢花了3.690秒，讓我們看一下使用了覆蓋索引優(yōu)化會(huì)提升多少性能吧。

# 使用了覆蓋索引
select id, `text` from t5 order by text limit 1000000, 10;

從上面的對(duì)比中，超大分頁(yè)查詢中，使用了覆蓋索引之后，花了0.201秒，而沒有使用覆蓋索引花了3.690秒，提高了18倍多，這在實(shí)際開發(fā)中，就是一個(gè)大的性能優(yōu)化了。（該數(shù)據(jù)在我的mbp上運(yùn)行得出）

2、子查詢優(yōu)化

因?yàn)閷?shí)際開發(fā)中，用SELECT查詢一兩列操作是非常少的，因此上述的覆蓋索引的適用范圍就比較有限。

所以我們可以通過(guò)把分頁(yè)的SQL語(yǔ)句改寫成子查詢的方法獲得性能上的提升。

select * from t5 where id>=(select id from t5 order by text limit 1000000, 1) limit 10;

其實(shí)使用這種方法，提升的效率和上面使用了覆蓋索引基本一致。

但是這種優(yōu)化方法也有局限性：

• 這種寫法，要求主鍵ID必須是連續(xù)的
• Where子句不允許再添加其他條件

 3、延遲關(guān)聯(lián)

和上述的子查詢做法類似，我們可以使用JOIN，先在索引列上完成分頁(yè)操作，然后再回表獲取所需要的列。

select a.* from t5 a inner join (select id from t5 order by text limit 1000000, 10) b on a.id=b.id;

從實(shí)驗(yàn)中可以得出，在采用JOIN改寫后，上面的兩個(gè)局限性都已經(jīng)解除了，而且SQL的執(zhí)行效率也沒有損失。

4、記錄上次查詢結(jié)束的位置

和上面使用的方法都不同，記錄上次結(jié)束位置優(yōu)化思路是使用某種變量記錄上一次數(shù)據(jù)的位置，下次分頁(yè)時(shí)直接從這個(gè)變量的位置開始掃描，從而避免MySQL掃描大量的數(shù)據(jù)再拋棄的操作。

select * from t5 where id>=1000000 limit 10;

根據(jù)以上實(shí)驗(yàn)，不難得出，由于使用了主鍵索引做分頁(yè)操作，SQL的性能是最快的。

總結(jié)

• 介紹了超大分頁(yè)查詢性能過(guò)差的原因，還有分享了幾個(gè)優(yōu)化思路
• 超大分頁(yè)的優(yōu)化思路就是讓分頁(yè)的SQL盡量在最佳的性能區(qū)間執(zhí)行，不要觸發(fā)全表掃描即可
• 希望以上的分享，可以讓你們?cè)贛ySQL這條路上少走彎路～～～

參考資料

• 《MySQL性能優(yōu)化》第六章 查詢優(yōu)化性能
• 《數(shù)據(jù)庫(kù)查詢優(yōu)化器的藝術(shù)》

到此這篇關(guān)于MySQL優(yōu)化教程之超大分頁(yè)查詢的文章就介紹到這了,更多相關(guān)MySQL超大分頁(yè)查詢內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！