基本上只要是做後台開發，都會接觸到分頁這個需求或者功能吧。基本上大家都是會用mysql的limit來處理，而且我現在負責的專案也是這樣寫的。但是一旦資料量起來了，其實limit的效率會極其的低，這一篇文章就來講一下limit子句優化的。
很多業務場景都需要用到分頁這個功能，基本上都是用limit來實現。
建表並且插入200萬條資料：
# 新建一張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;
# 建立儲存過程插入200萬資料
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;
# 呼叫儲存過程插入200萬資料
call t5_insert_200w();
在翻頁比較少的情況下，limit是不會出現任何效能上的問題的。
但是如果使用者需要查到最後面的頁數呢？
通常情況下，我們要保證所有的頁面可以正常跳轉，因為不會使用order by *** desc這樣的倒序sql來查程式設計客棧詢後面的頁數，而是採用正序順序來做分頁查詢：
select * from t5 order by text limit 100000, 10;
採用這種sql查詢分頁的話，從200萬資料中取出這10行資料的代價是非常大的，需要先排序查出前1000010條記錄，然後拋棄前面1000000條。我的macbook pro跑出來花了5.578秒。
接下來我們來看一下，上面這條sql語句的執行計畫：
explain select * from t5 order by text limit 1000000, 10;
從執行計畫可以看出，在大分頁的情況下，mysql沒有走索引掃瞄，即使text欄位我已經加上了索引。
這是為什麼呢？
回到mysql索引（二）如何設計索引中有提及到，mysql資料庫的查詢優化器是採用了基於代價的，而查詢代價的估算是基於cpu代價和io代價。
如果mysql在查詢代價估算中，認為全表掃瞄方式比走索引掃瞄的方式效率更高的話，就會放棄索引，直接全表掃瞄。
這就是為什麼在大分頁的sql查詢中，明明給該字段加了索引，但是mysql卻走了全表掃瞄的原因。
然後我們繼續用上面的查詢sql來驗證我的猜想：
explain select * from t5 order by text limit 7774, 10;
explain select * from t5 or by text limit 7775, 10;
以上的實驗均在我的mbp上執行的，在7774這個臨界點上，mysql分別採用了索引掃瞄和全表掃瞄的查詢優化方式。
所以可以認為mysql會根據它自己的代價查詢優化器來判斷是否使用索引。
由於mysql的查詢優化器的演算法核心是我們無法人工干預的，所以我們的優化思路就要著手於如何讓分頁維持在程式設計客棧最佳的的分頁臨界點。
如果一條sql語句，通過索引可以直接獲取查詢的結果，不再需要回表查詢，就稱這個索引為覆蓋索引。
在mysql資料庫中使用explain關鍵字檢視執行計畫，如果extra這一列顯示using index，就表示這條sql語句使用了覆蓋索引。
讓我們來對比一下使用了覆蓋索引，效能會提公升多少吧。
# 沒有使用覆蓋索引
select * from t5 order by text limit 1000000, 10;
這次查詢花了3.690秒，讓我們看一下使用了覆蓋索引優化會提公升多少效能吧。
# 使用了覆蓋索引
select id, `text` from t5 order by text limit 1000000, 10;
從上面的對比中，超大分頁查詢中，使用了覆蓋索引之後，花了0.201秒，而沒有使用覆蓋索引花了3.690秒，提高了18倍多，這在實際開發中，就是乙個大的效能優化了。（該資料在我的mbp上執行得出）
因為實際開發中，用select查詢一兩列操作是非常少的，因此上述的覆蓋索引的適用範圍就比較有限。
所以我們可以通過把分頁的sql語句改寫成子查詢的方法獲得效能上的提公升。
select * from t5 where id>=(select id from t5 ord程式設計客棧er by text limit 1000000, 1) limit 10;
其實使用這種方法，提公升的效率和上程式設計客棧面使用了覆蓋索引基本一致。
但是這種優化方法也有侷限性：
和上述的子查詢做法類似，我們可以使用join，先在索引列上完成分頁操作，然後再回表獲取所需要的列。
select a.* from t5 a inner join (select id from t5 order by text limit 1000000, 10) b on a.id=b.id;
從實驗中可以得出，在採用join改寫後，上面的兩個侷限性都已經解除了，而且sql的執行效率也沒有損失。
和上面使用的方法都不同，記錄上次結束位置優化思路是使用某種變數記錄上一次資料的位置，下次分頁時直接從這個變數的位置開始掃瞄，從而避免mysql掃瞄大量的資料再拋棄的操作。
select * from t5 where id>=1000000 limit 10;
根據以上實驗，不難得出，由於使用了主鍵索引做分頁操作，sql的效能是最快的。
參考資料
怎麼解決Mysql的超大分頁
用id優化 先找到上次分頁的最大id,然後利用id上的索引來查詢,類似於select from user where id 1000000 limit 100.這樣的效率非常快,因為主鍵上是有索引的,但是這樣有個缺點,就是id必須是連續的,並且查詢不能有where語句,因為where語句會造成過濾資...
MySQL的limit使用及解決超大分頁問題
limit語法支援兩個引數,offset和limit,前者表示偏移量,後者表示取前limit條資料.例如 返回符合條件的前10條語句select from user limit 10返回符合條件的第11 20條資料select from user limit10,20複製 從上面也可以看出來,lim...
Mysql騷操作 優化大分頁查詢
系統結構如上圖。經過排查是因為系統b拉取資料時間太長導致的推送超時。系統b拉取資料的方法是根據 tiemstamp 資料操作時間 分頁查詢系統a的介面,即 1select 欄位名2from 表名3where timestamp begintime and timestamp endtime 4lim...