2. 程式人生 > >[MySQL優化案例]系列 — 分頁優化

[MySQL優化案例]系列 — 分頁優化

阿新 • • 發佈：2019-02-15

通常，我們會採用ORDER BY LIMIT start, offset 的方式來進行分頁查詢。例如下面這個SQL：

SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 100, 10;

或者像下面這個不帶任何條件的分頁SQL：

SELECT * FROM `t1` ORDER BY id DESC LIMIT 100, 10;

一般而言，分頁SQL的耗時隨著 start 值的增加而急劇增加，我們來看下面這2個不同起始值的分頁SQL執行耗時：

[email protected]> SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 500, 10;
…

10 rows in set (0.05 sec)



 
[email protected]> SELECT * FROM `t1` WHERE ftype=6 ORDER BY id DESC LIMIT 935500, 10;
…

10 rows in set (2.39 sec)

可以看到，隨著分頁數量的增加，SQL查詢耗時也有數十倍增加，顯然不科學。今天我們就來分析下，如何能優化這個分頁方案。 一般滴，想要優化分頁的終極方案就是：沒有分頁，哈哈哈~~~，不要說我講廢話，確實如此，可以把分頁演算法交給Sphinx、Lucence等第三方解決方案，沒必要讓MySQL來做它不擅長的事情。 當然了，有小夥伴說，用第三方太麻煩了，我們就想用MySQL來做這個分頁，咋辦呢？莫急，且待我們慢慢分析，先看下錶DDL、資料量、查詢SQL的執行計劃等資訊：

[email protected]> SHOW CREATE TABLE `t1`;
CREATE TABLE `t1` (
 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
...
 `ftype` tinyint(3) unsigned NOT NULL,
...
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

[email protected]> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 994584 |
+----------+


 
[email protected]> EXPLAIN SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 500, 10\G
*************************** 1. row ***************************
 id: 1
 select_type: SIMPLE
 table: t1
 type: index
possible_keys: NULL
 key: PRIMARY
 key_len: 4
 ref: NULL
 rows: 510
 Extra: Using where

[email protected]> EXPLAIN SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 935500, 10\G
*************************** 1. row ***************************
 id: 1
 select_type: SIMPLE
 table: t1
 type: index
possible_keys: NULL
 key: PRIMARY
 key_len: 4
 ref: NULL
 rows: 935510
 Extra: Using where

可以看到，雖然通過主鍵索引進行掃描了，但第二個SQL需要掃描的記錄數太大了，而且需要先掃描約935510條記錄，然後再根據排序結果取10條記錄，這肯定是非常慢了。 針對這種情況，我們的優化思路就比較清晰了，有兩點：

1、儘可能從索引中直接獲取資料，避免或減少直接掃描行資料的頻率
2、儘可能減少掃描的記錄數，也就是先確定起始的範圍，再往後取N條記錄即可

據此，我們有兩種相應的改寫方法：子查詢、表連線，即下面這樣的：

#採用子查詢的方式優化，在子查詢裡先從索引獲取到最大id，然後倒序排，再取10行結果集
#注意這裡採用了2次倒序排，因此在取LIMIT的start值時，比原來的值加了10，即935510，否則結果將和原來的不一致
[email protected]> EXPLAIN SELECT * FROM (SELECT * FROM `t1` WHERE id > ( SELECT id FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 935510, 1) LIMIT 10) t ORDER BY id DESC\G
*************************** 1. row ***************************
 id: 1
 select_type: PRIMARY
 table: <derived2>
 type: ALL
possible_keys: NULL
 key: NULL
 key_len: NULL
 ref: NULL
 rows: 10
 Extra: Using filesort
*************************** 2. row ***************************
 id: 2
 select_type: DERIVED
 table: t1
 type: ALL
possible_keys: PRIMARY
 key: NULL
 key_len: NULL
 ref: NULL
 rows: 973192
 Extra: Using where
*************************** 3. row ***************************
 id: 3
 select_type: SUBQUERY
 table: t1
 type: index
possible_keys: NULL
 key: PRIMARY
 key_len: 4
 ref: NULL
 rows: 935511
 Extra: Using where

#採用INNER JOIN優化，JOIN子句裡也優先從索引獲取ID列表，然後直接關聯查詢獲得最終結果，這裡不需要加10
[email protected]> EXPLAIN SELECT * FROM `t1` INNER JOIN ( SELECT id FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 935500,10) t2 USING (id)\G
*************************** 1. row ***************************
 id: 1
 select_type: PRIMARY
 table: <derived2>
 type: ALL
possible_keys: NULL
 key: NULL
 key_len: NULL
 ref: NULL
 rows: 935510
 Extra: NULL
*************************** 2. row ***************************
 id: 1
 select_type: PRIMARY
 table: t1
 type: eq_ref
possible_keys: PRIMARY
 key: PRIMARY
 key_len: 4
 ref: t2.id
 rows: 1
 Extra: NULL
*************************** 3. row ***************************
 id: 2
 select_type: DERIVED
 table: t1
 type: index
possible_keys: NULL
 key: PRIMARY
 key_len: 4
 ref: NULL
 rows: 973192
 Extra: Using where

然後我們來對比下這2個優化後的新SQL執行時間：

[email protected]> SELECT * FROM (SELECT * FROM `t1` WHERE id > ( SELECT id FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 935510, 1) LIMIT 10) T ORDER BY id DESC;
...
rows in set (1.86 sec)
#採用子查詢優化，從profiling的結果來看，相比原來的那個SQL快了：28.2%

[email protected]> SELECT * FROM `t1` INNER JOIN ( SELECT id FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 935500,10) t2 USING (id);
...
10 rows in set (1.83 sec)
#採用INNER JOIN優化，從profiling的結果來看，相比原來的那個SQL快了：30.8%

我們再來看一個不帶過濾條件的分頁SQL對比：

#原始SQL
[email protected]> EXPLAIN SELECT * FROM `t1` ORDER BY id DESC LIMIT 935500, 10\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 935510
        Extra: NULL

[email protected]> SELECT * FROM `t1` ORDER BY id DESC LIMIT 935500, 10;
...
10 rows in set (2.22 sec)

#採用子查詢優化
[email protected]> EXPLAIN SELECT * FROM (SELECT * FROM `t1` WHERE id > ( SELECT id FROM `t1` ORDER BY id DESC LIMIT 935510, 1) LIMIT 10) t ORDER BY id DESC;
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: <derived2>
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10
        Extra: Using filesort
*************************** 2. row ***************************
           id: 2
  select_type: DERIVED
        table: t1
         type: ALL
possible_keys: PRIMARY
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 973192
        Extra: Using where
*************************** 3. row ***************************
           id: 3
  select_type: SUBQUERY
        table: t1
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 935511
        Extra: Using index

[email protected]> SELECT * FROM (SELECT * FROM `t1` WHERE id > ( SELECT id FROM `t1` ORDER BY id DESC LIMIT 935510, 1) LIMIT 10) t ORDER BY id DESC;
…
10 rows in set (2.01 sec)
#採用子查詢優化，從profiling的結果來看，相比原來的那個SQL快了：10.6%


#採用INNER JOIN優化
[email protected]> EXPLAIN SELECT * FROM `t1` INNER JOIN ( SELECT id FROM `t1`ORDER BY id DESC LIMIT 935500,10) t2 USING (id)\G
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: 
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 935510
        Extra: NULL
*************************** 2. row ***************************
           id: 1
  select_type: PRIMARY
        table: t1
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: t1.id
         rows: 1
        Extra: NULL
*************************** 3. row ***************************
           id: 2
  select_type: DERIVED
        table: t1
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 973192
        Extra: Using index

[email protected]> SELECT * FROM `t1` INNER JOIN ( SELECT id FROM `t1`ORDER BY id DESC LIMIT 935500,10) t2 USING (id);
…
10 rows in set (1.70 sec)
#採用INNER JOIN優化，從profiling的結果來看，相比原來的那個SQL快了：30.2%

至此，我們看到採用子查詢或者INNER JOIN進行優化後，都有大幅度的提升，這個方法也同樣適用於較小的分頁，雖然LIMIT開始的 start 位置小了很多，SQL執行時間也快了很多，但採用這種方法後，帶WHERE條件的分頁分別能提高查詢效率：24.9%、156.5%，不帶WHERE條件的分頁分別提高查詢效率：554.5%、11.7%，各位可以自行進行測試驗證。單從提升比例說，還是挺可觀的，確保這些優化方法可以適用於各種分頁模式，就可以從一開始就是用。 我們來看下各種場景相應的提升比例是多少：

大分頁，帶WHERE大分頁，不帶WHERE大分頁平均提升比例小分頁，帶WHERE小分頁，不帶WHERE總體平均提升比例
子查詢優化28.20%10.60%19.40%24.90%554.40%154.53%
INNER JOIN優化30.80%30.20%30.50%156.50%11.70%57.30%

結論：這樣看就和明顯了，尤其是針對大分頁的情況，因此我們優先推薦使用INNER JOIN方式優化分頁演算法。

上述每次測試都重啟mysqld例項，並且加了SQL_NO_CACHE，以保證每次都是直接資料檔案或索引檔案中讀取。如果資料經過預熱後，查詢效率會一定程度提升，但但上述相應的效率提升比例還是基本一致的。

2014/07/28後記更新：

其實如果是不帶任何條件的分頁，就沒必要用這麼麻煩的方法了，可以採用對主鍵採用範圍檢索的方法，例如參考這篇：Advance for MySQL Pagination

相關推薦

[MySQL優化案例]系列 — 分頁優化

通常，我們會採用ORDER BY LIMIT start, offset 的方式來進行分頁查詢。例如下面這個SQL：SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 100, 10; 或者像下面這個不帶任何條件的分頁SQL：SELECT * FRO

mysql 使用索引進行分頁優化

MySQL大資料量分頁查詢方法及其優化 ---方法1: 直接使用資料庫提供的SQL語句 ---語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N ---適應場景: 適用於資料量較少的情況(元組百/千級) ---原因/缺點: 全表掃描,速度會很慢 且

mysql 大資料量分頁優化

假設有一個千萬量級的表，取1到10條資料； select * from table limit 0,10; select * from table limit 1000,10; 這兩條語句查詢時間應該在毫秒級完成； select * from table limit

Oracle優化——單表分頁優化

傳參 邏輯讀 dbm statistic test alter har selected 多個 單表分頁優化思路：--創建測試表：SQL> create table t_test as select * from dba_objects; Table created.

MySQL分頁優化中的“INNER JOIN方式優化分頁算法”到底在什麽情況下會生效？

表結構 files key 效率 ref 兩個 ges 參考 如果 本文出處：http://www.cnblogs.com/wy123/p/7003157.html 最近無意間看到一個MySQL分頁優化的測試案例，並沒有非常具體地說明測試場景的情況下，給出了

Mysql分頁優化

mce 及其 過大 order by 意義 可能 就是 處理 con 　　在mysql中limit可以實現快速分頁，但是如果數據到了幾百萬時我們的limit必須優化才能有效的合理的實現分頁了，否則可能卡死你的服務器。當一個數據表中有幾百萬條數據的時候，就成問題了！ 　　例

MySQL 分頁優化

明顯 並不是 sql log family soft blog offset device MySQL 用 LIMIT offset, length 進行分頁。但當表記錄數很大，會發現大頁數的查詢時間明顯比小頁數的查詢時間大。 MySQL並不是跳過 offset 行，而是取

mysql量級數據表的分頁優化方案

lec undo ima BE ESS color info mar asc 前言 Limit分頁通用方案 select * from yundou_v3.bill_info limit 100,20; select * from yundou_v3.bill_info

百萬級資料庫記錄下的Mysql快速分頁優化例項

百萬級資料庫記錄下的Mysql快速分頁優化例項   MySql 效能到底能有多高？用了php半年多，真正如此深入的去思考這個問題還是從前天開始。有過痛苦有過絕望，到現在充滿信心！MySql 這個資料庫絕對是適合dba級的高手去玩的，一般做一點1萬篇新聞的小

MySQL大數據量分頁查詢方法及其優化

占用 對象 page 數據查詢 結果 sel 原因 希望 war ---方法1: 直接使用數據庫提供的SQL語句---語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N---適應場景: 適用於數據量較少的情況(元組百/千級)--

MySQL大資料量分頁查詢方法及其優化 MySQL大資料量分頁查詢方法及其優化

MySQL大資料量分頁查詢方法及其優化   ---方法1: 直接使用資料庫提供的SQL語句---語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N ---適應場景: 適用於資料量較少的情況(元組百/千級) --

MySQL大資料量分頁查詢方法及其優化 ---方法1: 直接使用資料庫提供的SQL語句 ---語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N ---適

測試實驗 1.   直接用limit start, count分頁語句， 也是我程式中用的方法： select * from product limit start, count 當起始頁較小時，查詢沒有效能問題，我們分別看下從10， 100， 1000， 10000開始分頁的執行時間（每頁取20條）， 如

MySQL MyISAM和InnoDB引擎的寫入速度優化比較，分頁速度優化

以下的文章主要介紹的是MySQL MyISAM的引擎和InnoDB引擎的實際效能的比較，我們首先是通過MySQL資料庫的表結構來出MySQL MyISAM的引擎和InnoDB引擎的實際效能的實際操作。 幫助 01 02 03 04 05

MySQL大資料量分頁查詢方法及其優化

方法1: 直接使用資料庫提供的SQL語句 語句樣式: MySQL中,可用如下方法: SELECT * FROM 表名稱 LIMIT M,N 適應場景: 適用於資料量較少的情況(元組百/千級) 原因/缺點: 全表掃描,速度會很慢 且 有的資料庫結果集返回不穩定(如某次返回

千萬級MySQL分頁優化

對於只有幾萬條資料的表這樣做當然沒問題,也不會在使用者體驗上有何不妥,但是要是面對成百萬上千萬的資料表時,這樣就不足以滿足我們的業務需求了,如何做到對千萬級資料表進行高效分頁?首先要學會使用 explain 對你的SQL進行分析,如果你還不會使用 explain 分析SQL語

mongodb系列之五：java分頁優化

前面我們提到過，大資料量分頁時，skip如果跳過大量的資料會很慢，這裡針對這一情況，我們優化一下分頁。 看程式碼： [java] view plaincopyprint? /**       * 大資料量資料分頁優化       * @param pa

如何優化Mysql千萬級快速分頁,limit優化快速分頁,MySQL處理千萬級資料查詢的優化方案！（zz）

MySQL資料庫優化處理實現千萬級快速分頁分析，來看下吧。 資料表 collect ( id, title ,info ,vtype) 就這4個欄位，其中 title 用定長，info 用text, id 是逐漸，vtype是tinyint，vtype是索引。這是一個基本的新聞系統的簡單模型。現在往裡面填

MySQL大資料量分頁SQL語句優化

分頁程式原理很簡單，這裡就不多說了，本篇文章主要說的是在資料表記錄量比較大的情況下，如何將分頁SQL做到更優化，讓MySQL執行的更快的方法。 一般的情況下，我們的分頁SQL語句是這樣的：

從官方文件中探索MySQL分頁的幾種方式及分頁優化

### 概覽 相比於Oracle，SQL Server 等資料庫，MySQL分頁的方式簡單得多了，官方自帶了分頁語法 `limit` 語句: ```sql select * from test_t LIMIT {[offset,] row_count | row_count OFFSET offset}

SQL通用優化方案(where優化、索引優化、分頁優化、事務優化、臨時表優化)

truncate height 能夠 時有 大數據量 2017年 固然 分頁 索引優化 SQL通用優化方案:1. 使用參數化查詢：防止SQL註入，預編譯SQL命令提高效率2. 去掉不必要的查詢和搜索字段：其實在項目的實際應用中，很多查詢條件是可有可無的，能從源頭上避免的多余