今天小編給大家分享一下如何解決MySQL深分頁問題的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

創(chuàng)新互聯公司是專業(yè)的米東網站建設公司，米東接單;提供網站制作、做網站,網頁設計,網站設計,建網站,PHP網站建設等專業(yè)做網站服務;采用PHP框架,可快速的進行米東網站開發(fā)網頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網站,專業(yè)的做網站團隊,希望更多企業(yè)前來合作!

日常需求開發(fā)過程中，相信大家對于limit一定不會陌生，但是使用limit時，當偏移量（offset）非常大時，會發(fā)現查詢效率越來越慢。一開始limit 2000時，可能200ms,就能查詢出需要的到數據，但是當limit 4000 offset 100000時，會發(fā)現它的查詢效率已經需要1S左右，那要是更大的時候呢，只會越來越慢。

概括

本文將會討論當mysql表大數據量的情況，如何優(yōu)化深分頁問題，并附上最近的優(yōu)化慢sql問題的案例偽代碼。

1、limit深分頁問題描述

先看看表結構（隨便舉了個例子，表結構不全，無用字段就不進行展示了）

CREATE TABLE `p2p_detail_record` (
  `id` varchar(32) COLLATE utf8mb4_bin NOT NULL DEFAULT '' COMMENT '主鍵',
  `batch_num` int NOT NULL DEFAULT '0' COMMENT '上報數量',
  `uptime` bigint NOT NULL DEFAULT '0' COMMENT '上報時間',
  `uuid` varchar(64) COLLATE utf8mb4_bin NOT NULL DEFAULT '' COMMENT '會議id',
  `start_time_stamp` bigint NOT NULL DEFAULT '0' COMMENT '開始時間',
  `answer_time_stamp` bigint NOT NULL DEFAULT '0' COMMENT '應答時間',
  `end_time_stamp` bigint NOT NULL DEFAULT '0' COMMENT '結束時間',
  `duration` int NOT NULL DEFAULT '0' COMMENT '持續(xù)時間',
  PRIMARY KEY (`id`),
  KEY `idx_uuid` (`uuid`),
  KEY `idx_start_time_stamp` (`start_time_stamp`) //索引,
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='p2p通話記錄詳情表';

假設我們要查詢的深分頁SQL長這樣

select * 
from p2p_detail_record ppdr 
where ppdr .start_time_stamp >1656666798000 
limit 0,2000

查詢效率是94ms，是不是很快？那如果我們limit 100000，2000呢，查詢效率是1.5S，已經非常慢，那如果更多呢？

2、sql慢原因分析

讓我們來看看這條sql的執(zhí)行計劃

也走到了索引，那為什么還是慢呢？我們先來回顧一下mysql 的相關知識點。

聚簇索引和非聚簇索引

聚簇索引：葉子節(jié)點儲存的是整行的數據。

非聚簇索引：葉子節(jié)點儲存的是整行的數據對應的主鍵值。

使用非聚簇索引查詢的流程

• 通過非聚簇索引樹，找到對應的葉子節(jié)點，獲取到主鍵的值。

• 再通過取到主鍵的值，回到聚簇索引樹，找到對應的整行數據。（整個過程稱為回表）

回到這條sql為什么慢的問題上，原因如下

1、limit語句會先掃描offset+n行，然后再丟棄掉前offset行，返回后n行數據。也就是說limit 100000,10，就會掃描100010行，而limit 0,10，只掃描10行。這里需要回表100010次，大量的時間都在回表這個上面。

方案核心思路：能不能事先知道要從哪個主鍵ID開始，減少回表的次數

常見解決方案

通過子查詢優(yōu)化

select * 
from p2p_detail_record ppdr 
where id >= (select id from p2p_detail_record ppdr2 where ppdr2 .start_time_stamp >1656666798000 limit 100000,1) 
limit 2000

相同的查詢結果，也是10W條開始的第2000條，查詢效率為200ms，是不是快了不少。

標簽記錄法

標簽記錄法：其實標記一下上次查詢到哪一條了，下次再來查的時候，從該條開始往下掃描。類似書簽的作用

select * from p2p_detail_record ppdr
where ppdr.id > 'bb9d67ee6eac4cab9909bad7c98f54d4'
order by id 
limit 2000

備注：bb9d67ee6eac4cab9909bad7c98f54d4是上次查詢結果的最后一條ID

使用標簽記錄法，性能都會不錯的，因為命中了id索引。但是這種方式有幾個缺點。

• 1、只能連續(xù)頁查詢，不能跨頁查詢。

• 2、需要一種類似連續(xù)自增的字段（可以使用orber by id的方式）。

方案對比

• 使用通過子查詢優(yōu)化的方式

優(yōu)點：可跨頁查詢，想查哪一頁的數據就查哪一頁的數據。

缺點：效率不如標簽記錄法。原因：比如需要查10W條數據后，第1000條，也需要先查詢出非聚簇索引對應的10W1000條數據，在取第10W開始的ID，進行查詢。

• 使用 標簽記錄法的方式

優(yōu)點：查詢效率很穩(wěn)定，非?？臁?/p>

缺點：

• 不跨頁查詢，

• 需要一種類似連續(xù)自增的字段

關于第二點的說明：該點一般都好解決，可使用任意不重復的字段進行排序即可。若使用可能重復的字段進行排序的字段，由于mysql對于相同值的字段排序是無序，導致如果正好在分頁時，上下頁中可能存在相同的數據。

實戰(zhàn)案例

需求：需要查詢查詢某一時間段的數據量，假設有幾十萬的數據量需要查詢出來，進行某些操作。

需求分析1、分批查詢（分頁查詢），設計深分頁問題，導致效率較慢。

CREATE TABLE `p2p_detail_record` (
  `id` varchar(32) COLLATE utf8mb4_bin NOT NULL DEFAULT '' COMMENT '主鍵',
  `batch_num` int NOT NULL DEFAULT '0' COMMENT '上報數量',
  `uptime` bigint NOT NULL DEFAULT '0' COMMENT '上報時間',
  `uuid` varchar(64) COLLATE utf8mb4_bin NOT NULL DEFAULT '' COMMENT '會議id',
  `start_time_stamp` bigint NOT NULL DEFAULT '0' COMMENT '開始時間',
  `answer_time_stamp` bigint NOT NULL DEFAULT '0' COMMENT '應答時間',
  `end_time_stamp` bigint NOT NULL DEFAULT '0' COMMENT '結束時間',
  `duration` int NOT NULL DEFAULT '0' COMMENT '持續(xù)時間',
  PRIMARY KEY (`id`),
  KEY `idx_uuid` (`uuid`),
  KEY `idx_start_time_stamp` (`start_time_stamp`) //索引,
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='p2p通話記錄詳情表';

偽代碼實現：

//最小ID 
String  lastId = null; 
//一頁的條數 
Integer pageSize = 2000; 
List list ;
do{   
   list = listP2pRecordByPage(lastId,pageSize);    //標簽記錄法，記錄上次查詢過的Id 
   lastId = list.get(list.size()-1).getId();       //獲取上一次查詢數據最后的ID，用于記錄
   //對數據的操作邏輯
   XXXXX();
 }while(isNotEmpty(list));
   
  
   select * 
   from p2p_detail_record ppdr where 1=1
   
   and ppdr.id > #{lastId}
   
   order by id asc
   limit #{pageSize}

這里有個小優(yōu)化點:可能有的人會先對所有數據排序一遍，拿到最小ID，但是這樣對所有數據排序，然后去min（id),耗時也蠻長的，其實第一次查詢，可不帶lastId進行查詢，查詢結果也是一樣。速度更快。

以上就是“如何解決mysql深分頁問題”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注創(chuàng)新互聯行業(yè)資訊頻道。