背景
基本上只要是做後台開發，都會接觸到分頁這個需求或者功能吧。基本上大家都是會用mysql的limit來處理，而且我現在負責的專案也是這樣寫的。但是一旦資料量起來了，其實limit的效率會極其的低，這一篇文章就來講一下limit子句優化的。
limit優化
很多業務場景都需要用到分頁這個功能，基本上都是用limit來實現。
建表並且插入200萬條資料：
create tablet5(
idint not null auto_increment,
namevarchar(50) not null,
textvarchar(100) not null,
primary key (id),
keyix_name(name),
keyix_test(text)
) engine=innodb default charset=utf8;
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;
call t5_insert_200w();12
3456
78910
1112
1314
1516
1718
1920
2122
23在翻頁比較少的情況下，limit是不會出現任何效能上的問題的。
但是如果使用者需要查到最後面的頁數呢？
通常情況下，我們要保證所有的頁面可以正常跳轉，因為不會使用order by *** desc這樣的倒序sql來查詢後面的頁數，而是採用正序順序來做分頁查詢：
select * from t5 order by text limit 100000, 10;
1在這裡插入描述
採用這種sql查詢分頁的話，從200萬資料中取出這10行資料的代價是非常大的，需要先排序查出前1000010條記錄，然後拋棄前面1000000條。我的macbook pro跑出來花了5.578秒。
接下來我們來看一下，上面這條sql語句的執行計畫：
explain select * from t5 order by text limit 1000000, 10;
1在這裡插入描述
從執行計畫可以看出，在大分頁的情況下，mysql沒有走索引掃瞄，即使text欄位我已經加上了索引。
這是為什麼呢？
回到mysql索引（二）如何設計索引中有提及到，mysql資料庫的查詢優化器是採用了基於代價的，而查詢代價的估算是基於cpu代價和io代價。
如果mysql在查詢代價估算中，認為全表掃瞄方式比走索引掃瞄的方式效率更高的話，就會放棄索引，直接全表掃瞄。
mysql優化之mysql查詢效能排序分析
mysql 查詢效能排序，從左至右，效能由最差到最好 all index range ref eq ref const system null 1.all 全表掃瞄 例 select from user 2.index 索引全掃瞄 例 select id from user 3.range 索引範圍...
MySQL優化教程之超大分頁查詢
基本上只要是做後台開發，都會接觸到分頁這個需求或者功能吧。基本上大家都是會用mysql的limit來處理，而且我現在負責的專案也是這樣寫的。但是一旦資料量起來了，其實limit的效率會極其的低，這一篇文章就來講一下limit子句優化的。很多業務場景都需要用到分頁這個功能，基本上都是用limit來實現...
MySQL 一 分頁查詢
mysql 的limit limit 子句可以被用於強制 select 語句返回指定的記錄數。limit 接受乙個或兩個數字引數。引數必須是乙個整數常量。如果給定兩個引數，第乙個引數指定第乙個返回記錄行的偏移量，第二個引數指定返回記錄行的最大數目。初始記錄行的偏移量是 0 而不是 1 limit分頁...