在 MySQL 中通常我們使用 limit 來完成頁面上的分頁功能，但是當資料量達到一個很大的值之後，越往後翻頁，介面的響應速度就越慢。

本文主要討論 limit 分頁大偏移量慢的原因及優化方案，為了模擬這種情況，下面首先介紹表結構和執行的 SQL。

場景模擬

建表語句

user 表的結構比較簡單，id、sex 和 name，為了讓 SQL 的執行時間變化更加明顯，這裡有9個姓名列。

CREATE TABLE `user` (
 `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵',`sex` tinyint(4) NULL DEFAULT NULL COMMENT '性別 0-男 1-女',`name1` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '姓名',`name2` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '姓名',`name3` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '姓名',`name4` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '姓名',`name5` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '姓名',`name6` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '姓名',`name7` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '姓名',`name8` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '姓名',`name9` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '姓名',PRIMARY KEY (`id`) USING BTREE,INDEX `sex`(`sex`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 9000001 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;

資料填充

這裡建立了一個儲存過程來進行資料的填充，一共9000000條資料，執行完函式後再執行一句SQL，修改性別欄位。

ps:這個函式執行的挺久的，我運行了617.284秒。

CREATE DEFINER=`root`@`localhost` PROCEDURE `data`()
begin 
 declare i int; 
 set i=1; 
 while(i<=9000000)do 
  insert into user values(i,i,i);
  set i=i+1; 
 end while;
end

-- 將id為偶數的user設定性別為1-女
update user set sex=1 where id%2=0;

SQL與執行時間

SQL	執行時間
select * from user where sex = 1 limit 100,10;	OK,Time: 0.005000s
select * from user where sex = 1 limit 1000,Time: 0.007000s
select * from user where sex = 1 limit 10000,Time: 0.016000s
select * from user where sex = 1 limit 100000,Time: 0.169000s
select * from user where sex = 1 limit 1000000,Time: 5.892000s
select * from user where sex = 1 limit 10000000,Time: 33.465000s

可以看到，limit 的偏移量越大，執行時間越長。

原因分析

首先來分析一下這句 SQL 執行的過程，就拿上面表格中的第一行來舉例。

由於 sex 列是索引列，MySQL會走 sex 這棵索引樹，命中 sex=1 的資料。

然後又由於非聚簇索引中儲存的是主鍵 id 的值，且查詢語句要求查詢所有列，所以這裡會發生一個回表的情況，在命中 sex 索引樹中值為1的資料後，拿著它葉子節點上的值也就是主鍵 id 的值去主鍵索引樹上查詢這一行其他列（name、sex）的值，最後返回到結果集中，這樣第一行資料就查詢成功了。

最後這句 SQL 要求limit 100,10，也就是查詢第101到110個數據，但是 MySQL 會查詢前110行，然後將前100行拋棄，最後結果集中就只剩下了第101到110行，執行結束。

小結一下，在上述的執行過程中，造成 limit 大偏移量執行時間變久的原因有：

• 查詢所有列導致回表
• limit a,b會查詢前a+b條資料，然後丟棄前a條資料
  

綜合上述兩個原因，MySQL 花費了大量時間在回表上，而其中a次回表的結果又不會出現在結果集中，這才導致查詢時間變得越來越長。

優化方案

覆蓋索引

既然無效的回表是導致查詢變慢的主要原因，那麼優化方案就主要從減少回表次數方面入手，假設在limit a,b中我們首先得到了a+1到a+b條資料的id，然後再進行回表獲取其他列資料，那麼就減少了a次回表操作，速度肯定會快上不少。

這裡就涉及到覆蓋索引了，所謂的覆蓋索引就是從非主聚簇索引中就能查到的想要資料，而不需要通過回表從主鍵索引中查詢其他列，能夠顯著提升效能。

基於這樣的思路，優化方案就是先查詢得到主鍵id，然後再根據主鍵id查詢其他列資料，優化後的 SQL 以及執行時間如下表。

優化後的 SQL	執行時間
select * from user a join (select id from user where sex = 1 limit 100,10) b on a.id=b.id;	OK,Time: 0.000000s
select * from user a join (select id from user where sex = 1 limit 1000,Time: 0.00000s
select * from user a join (select id from user where sex = 1 limit 10000,Time: 0.002000s
select * from user a join (select id from user where sex = 1 limit 100000,Time: 0.015000s
select * from user a join (select id from user where sex = 1 limit 1000000,Time: 0.151000s
select * from user a join (select id from user where sex = 1 limit 10000000,Time: 1.161000s

果然，執行效率得到了顯著提升。

條件過濾

當然還有一種有缺陷的方法是基於排序做條件過濾。

比如像上面的示例 user 表，我要使用 limit 分頁得到1000001到1000010條資料，可以這樣寫 SQL：

select * from user where sex = 1 and id > (select id from user where sex = 1 limit 1000000,1) limit 10;

但是使用這樣的方式優化是有條件的：主鍵id必須是有序的。在有序的條件下，也可以使用比如建立時間等其他欄位來代替主鍵id，但是前提是這個欄位是建立了索引的。

總之，使用條件過濾的方式來優化 limit 是有諸多限制的，一般還是推薦使用覆蓋索引的方式來優化。

小結

主要分析了 limit 分頁大偏移量慢的原因，同時也提出了響應的優化方案，推薦使用覆蓋索引的方式來優化 limit 分頁大偏移執行時間久的問題。

希望能幫助到大家。

以上就是MySQL limit分頁大偏移量慢的原因及優化方案的詳細內容，更多關於MySQL limit 分頁的資料請關注我們其它相關文章！