MySQL深度分頁的問題及優化方案：千萬級數據量如何快速分頁

前言

後端開發中爲了防止一次性加載太多數據致使內存、磁盤IO都開銷過大，常常須要分頁展現，這個時候就須要用到MySQL的LIMIT關鍵字。但你覺得LIMIT分頁就萬事大吉了麼，Too young,too simple啊，LIMIT在數據量大的時候很可能形成的一個問題就是深度分頁。

案例

這裏我以顯示電商訂單詳情爲背景舉個例子，新建表以下：

CREATE TABLE `cps_user_order_detail` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵',
  `user_id` varchar(32) NOT NULL DEFAULT '' COMMENT '用戶ID',
  `order_id` bigint(20) DEFAULT NULL COMMENT '訂單id',
  `sku_id` bigint(20) unsigned NOT NULL COMMENT '商品ID',
  `order_time` datetime DEFAULT NULL COMMENT '下單時間,格式yyyy-MM-dd HH:mm:ss',
   PRIMARY KEY (`id`),
   KEY `idx_time_user` (`order_time`,`user_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='用戶訂單詳情';

而後手動向表裏插入120W條數據。
如今有個需求：分頁展現用戶的訂單詳情，按照下單時間倒序。
表結構精簡了，需求也簡單。因而嘩嘩嘩的寫完代碼，提測上線了。早期運行一切正常，可隨着訂單量的不斷增大，發現系統愈加的緩慢，還時不時報出幾個慢查詢。
這個時候你就該想到是LIMIT偏移的問題了，沒錯，不是你的SQL不夠優美，就是MySQL自身的機制。
這裏我就簡單以兩條SQL爲例，以下圖，分別是從100和100W的位置偏移分頁，能夠看到時間相差很大。這還不算其它數據運算和處理的時間，單一條SQL的查詢就耗時一秒以上，在對用戶提供的功能裏這是不能容忍的（電商裏常常要求一個接口的RT不超過200ms）。

這裏咱們再看下執行計劃，以下圖所示：

在此先介紹一下執行計劃Extra列可能出現的值及含義：

1. Using where：表示優化器須要經過索引回表查詢數據。
2. Using index：即覆蓋索引，表示直接訪問索引就足夠獲取到所須要的數據，不須要經過索引回表，一般是經過將待查詢字段創建聯合索引實現。
3. Using index condition：在5.6版本後加入的新特性，即大名鼎鼎的索引下推，是MySQL關於減小回表次數的重大優化。
4. Using filesort:文件排序，這個通常在ORDER BY時候，數據量過大，MySQL會將全部數據召回內存中排序，比較消耗資源。

再看看上圖，一樣的語句，只覺得偏移量不一樣，就形成了執行計劃的千差萬別（且容我小小的誇張一下）。第一條語句LIMIT 100,6type列的值是range，表示範圍掃描，性能比ref差一個級別，可是也算走了索引，而且還應用了索引下推：就是說在WHERE以後的下單時間刪選走了索引，而且以後的ORDER BY也是根據索引下推優化，在執行WHERE條件篩選時同步進行的（沒有回表）。
而第二條語句LIMIT 1000000,6壓根就沒走索引，type列的值是ALL，顯然是全表掃描。而且Extra列字段裏的Using where表示發生了回表，Using filesort表示ORDER BY時發生了文件排序。因此這裏慢在了兩點：一是文件排序耗時過大，二是根據條件篩選了相關的數據以後，須要根據偏移量回表獲取所有值。不管是上面的哪一點，都是LIMIT偏移量過大致使的，因此實際開發環境常常遇到非統計表量級不得超過一百萬的要求。

優化

緣由分析完了，那麼LIMIT深度分頁在實際開發中怎麼優化呢？這裏少俠給兩點方案。
一是經過主鍵索引優化。什麼意思呢？就是把上面的語句修改爲：

SELECT * FROM cps_user_order_detail d WHERE d.id > #{maxId} AND d.order_time>'2020-8-5 00:00:00' ORDER BY d.order_time LIMIT 6;

如上代碼所示，一樣也是分頁，可是有個maxId的限制條件，這個是什麼意思呢，maxId就是上一頁中的最大主鍵Id。因此採用此方式的前提：1）主鍵必須自增不能是UUID而且前端除了傳基本分頁參數pageNo,pageSize外，還必須把每次上一頁的最大Id帶過來，2）該方式不支持隨機跳頁，也就是說只能上下翻頁。以下圖所示是某知名電商中的實際頁面。

二是經過Elastic Search搜索引擎（基於倒排索引），實際上相似於淘寶這樣的電商基本上都是把全部商品放進ES搜索引擎裏的（那麼海量的數據，放進MySQL是不可能的，放進Redis也不現實）。但即便用了ES搜索引擎，也仍是有可能發生深度分頁的問題的，這時怎麼辦呢？答案是經過遊標scroll。關於此點這裏不作深刻，感興趣的能夠作研究。

小結

寫這篇博客是由於前段時間在開發中真實經歷到了，而且以前在字節面試中確實也和麪試官探討了一番。知道LIMIT的限制以及優化，在面試中能提到是加分項，不能說到MySQL優化就是建索引，調整SQL（實際上在真實開發中這兩種優化方案的成效微乎其微）。畢竟MySQL優化那麼牛X的話，就不會有那麼多中間件產生了。
我是少俠露飛，愛技術，愛分享。